](./images/App_Overview.png?raw=true)
-[
](./images/App_Launchpad.png?raw=true)
-[
](./images/App_Assessment_01.png?raw=true)
-[
](./images/App_Assessment_02.png?raw=true)
+[
](./images/App_Architecture_Kyma.png?raw=true)
-As you might have noticed, the architectures of the Kyma and Cloud Foundry are pretty much similar. Same applies for the provided sample code, which only differs in a few runtime specific aspects but is otherwise runtime independent. Anyway, for the Kubernetes experts amongst you, please feel free to check out a more detailed and Kubernetes focused architecture below. If you are new to Kubernetes, don't worry as we will get you covered along the way if you decide to walk along the Kyma path.
+As you might have noticed, the architectures of the Kyma and Cloud Foundry are pretty much similar. Same applies for the provided sample code, which only differs in a few runtime specific aspects but is otherwise runtime independent.
+
+> **Important** - All deployment related artifacts have been removed from the actual code-line into a separate *deploy* directory, so the actual *code* is (except for a few spots) completely runtime independent!
+
+For the Kubernetes experts amongst you, please feel free to check out a more detailed and Kubernetes focused architecture below. If you are new to Kubernetes, don't worry as we will get you covered along the way if you decide to walk along the Kyma path.
+
+**Kyma**
[
](./images/App_ArchitectureDetails.png?raw=true)
@@ -41,28 +53,37 @@ This tutorial is structured in three major versions which are the **Basic** and
**Basic Version**
-The **Basic Version** contains a very comprehensive version of the **SusaaS (Sustainable SaaS)** application, which can be deployed to your SAP BTP account using **free (tier) service plans** only. You can use any SAP BTP account type including Trial accounts to deploy this version of the sample application to either a Kyma or Cloud Foundry environment. Furthermore, the Basic Version is the foundation of the Advanced Version and contains the most important components of a SAP BTP SaaS solution (including an Inbound API).
+The **Basic Version** contains a very comprehensive version of the **SusaaS (Sustainable SaaS)** application, which can be deployed to your SAP BTP account using **Free (Tier)** or even **Trial** service plans.
+
+You can use any SAP BTP account type (including Trial) to deploy this version of the sample application to either a Kyma or Cloud Foundry environment. Furthermore, the Basic Version is the foundation of the Advanced Version and contains essential components of a SAP BTP SaaS solution (including a multitenant API).
+
**Advanced Version**
The **Advanced** version adds further enterprise features to your SAP BTP SaaS application like
-- a SAP S/4HANA backend pushing data to the SaaS APIs
-- SAP API Management for managing your SaaS API
-- a central user management in SAP Identity Authentication Service
+- a Central User Management in SAP Identity Authentication Service (SAP IAS)
+- an integration with SAP API Management for managing your SaaS API
+- a sample showcasing how to push data from an SAP S/4HANA backend
+
+
+All services required to complement the Advanced Version of the sample scenario are available in all SAP BTP account types including Trial accounts. The only exception is (for sure) an SAP S/4HANA system, which you either need to bring yourself or you need to set up a [CAL instance](https://cal.sap.com/) which will cost you a few dollars per month (don't forget to stop your system if not in use :).
+
+> **Hint** - If you don't have access to an SAP S/4HANA system, you can also use the HTTP test files provided as part of this tutorial for testing the multitenant API from a SaaS consumer perspective.
-All services required to complement the Advanced Version of the sample scenario are available in all SAP BTP account types including Trial accounts. The only exception is an SAP S/4HANA system, which you either need to bring yourself or you need to set up a [CAL instance](https://cal.sap.com/) which will cost you a few dollars per month (don't forget to stop your system if not in use :). You can also skip the respective part of the sample scenario.
**Expert Features**
-> **Important** - The Expert Features are still Work-in-Progress. The code and documentation are subject to change.
+> **Important** - The Expert Features are still Work-in-Progress and constantly evolving. The code and documentation are subject to change.
The **Expert Features** contain a lot of additional expert knowledge for developers implementing SaaS applications on SAP BTP. The different topics of the Expert Features mostly result from experiences of the latest learnings and challenges of a Proof-of-Concept which was conducted with SAP partners.
The topics include but are not limited to
+ - Local and hybrid testing of multitenant apps
+ - Applying extensions as a SaaS consumers
+ - Exploring feature toggles in a SaaS context
- Using a custom domain for your SaaS app
- Handling Tenant database containers
- Providing your SaaS application in multiple regions
- - Applying extensions for your SaaS consumers
- Integrating a customer's Identity Provider
- Sending e-mails using Microsoft Graph
- ...
@@ -70,20 +91,24 @@ The topics include but are not limited to
## 2. GitHub Repository
-You can find the code of the sample application in the following sap-samples GitHub repository. You can either clone or fork the repository to your own GitHub account.
+You can find the code of the sample application in the following SAP-samples GitHub repository. You can either clone or fork the repository to your own GitHub account.
https://github.com/SAP-samples/btp-cap-multitenant-saas
The repository contains one branch [**main**](https://github.com/SAP-samples/btp-cap-multitenant-saas/tree/main/) for the tutorial documentation, source code and deployment definitions like Helm Charts and MTA Deployment Descriptor files.
+> **Important** - The code-line is kept generic, so that in a few places you are required to provide your environment specific details. Please make sure to carefully read the step-by-step guide in this case, as we provide guidance on how to use the **-private** filename extension. This will ensure that no confidential or environment specific details will be committed to your GitHub repository.
+
## 3. Tutorial Audience
While the ecosystem of partner-built software for SAP On-Premise solutions has grown very well over the last decades, the available partner offerings and the interest in building solutions on SAP BTP starts to increase. A lot of SAP partners wonder how to port their existing developments to the cloud, to satisfy the demand of their existing customers moving to SAP BTP, or reach out to a much broader market than before.
-For that reason, this tutorial and the related topic of developing multitenant SaaS applications using the **SAP BTP, Cloud Foundry or Kyma Runtime** is of great interest to partners and customers. It is supposed to give all interested stakeholders an introduction to the theoretical basics of Software as a Service on SAP BTP and provides a great codebase that can be used to kickstart your own implementation.
+For that reason, this tutorial and the related topic of developing multitenant SaaS applications using the **SAP BTP, Cloud Foundry** or **Kyma Runtime** is of great interest to partners and customers. It is supposed to give all interested stakeholders an introduction to the theoretical basics of Software as a Service on SAP BTP and provides a great codebase that can be used to kickstart your own implementation.
+
+There is no previous development knowledge required for the **Cloud Foundry** sample of this tutorial, so all new but also experienced developers can set up the sample application. Nevertheless, a basic understanding of SAP BTP service offerings will help you grasp the ideas and concepts. Furthermore, you should have a basic idea how to use the SAP BTP Cockpit to assign entitlements, role-collections and similar foundational concepts.
-There is no previous knowledge required for this tutorial, so all new but also experienced developers can set up the sample application. Nevertheless, a basic understanding of SAP BTP service offerings will help you grasp the ideas and concepts.
+For the **Kyma** track, you will require at least some basic Kubernetes knowledge and ideally have a Kyma Cluster up and running in your environment. Furthermore, you should be familiar connecting to your Cluster using kubectl.
## 4. Focus Topics
@@ -100,6 +125,7 @@ The main topics of the tutorial include:
- APIs for flexible Subscriber data integration
- and many more...
* Expert topics to consider when building SaaS apps like
+ - development efficiency using local and hybrid testing
- set up a custom domain for your app
- deploying your app to multiple regions
- handling Tenant database containers
diff --git a/docu/1-discover/2-learn-basics-btp-cf-kyma/README.md b/docu/1-discover/2-learn-basics-btp-cf-kyma/README.md
index f8280b5..8b45cb4 100644
--- a/docu/1-discover/2-learn-basics-btp-cf-kyma/README.md
+++ b/docu/1-discover/2-learn-basics-btp-cf-kyma/README.md
@@ -13,9 +13,26 @@ The **SAP Business Technology Platform (SAP BTP)** is an integrated offering com
> **Hint** - Check the official documentation to learn more ([click here](https://help.sap.com/docs/btp/sap-business-technology-platform/sap-business-technology-platform)).
-SAP BTP offers users the ability to turn data into business value, compose end-to-end business processes, and build and extend SAP applications quickly. The services and solutions of SAP BTP are available on multiple cloud infrastructure providers. The multi-cloud foundation supports different environments, such as **Kyma**, **Cloud Foundry**, **ABAP Cloud**, as well as multiple different regions, and a broad choice of programming languages. This tutorial will provide detailed end-to-end deployment instructions on the **Cloud Foundry** as well as the **Kyma** Runtime.
+SAP BTP offers customers and partners the ability to turn data into business value, compose end-to-end business processes, and build and extend SAP applications quickly. The services and solutions of SAP BTP are available on multiple Cloud Infrastructure Providers in data centers all around the globe.
-The central point of entry to the platform is the SAP BTP Cockpit (see below), where you can access your accounts and applications and manage all activities associated with them. As this tutorial is not about an extensive SAP BTP introduction, we would like to refer you to the official [SAP Help](https://help.sap.com/docs/BTP/65de2977205c403bbc107264b8eccf4b/73beb06e127f4e47b849aa95344aabe1.html?locale=en-US) documentation for further information.
+- Amazon Web Services (AWS)
+- Microsoft Azure
+- Google Cloud Platform (GCP)
+- Ali Cloud
+
+The multi-cloud strategy supports different environments and runtimes for application development, such as **Kyma**, **Cloud Foundry**, **ABAP Cloud**, as well as multiple different regions, and a broad choice of programming languages. This tutorial will provide detailed end-to-end development guidance for the **Cloud Foundry** as well as the **Kyma** Runtime.
+
+The central point of entry to the platform is the SAP BTP Cockpit, where you can access your accounts and applications and manage all activities associated with them. You can find the region-specific URLs below.
+
+> **Hint** - You can use any of those links to access any of your SAP BTP accounts. The regional availability serves the performance of the Cockpit application, so we suggest to use the closest regional URL when working with the Cockpit.
+
+- EMEA: https://emea.cockpit.btp.cloud.sap
+- Restricted EU-Access: https://eu-access.cockpit.btp.cloud.sap
+- Americas: https://amer.cockpit.btp.cloud.sap
+- Asia-Pacific, Oceania: https://apac.cockpit.btp.cloud.sap
+- Trial: https://cockpit.hanatrial.ondemand.com/trial
+
+As this tutorial is not about an extensive SAP BTP introduction, we would like to refer you to the official [SAP Help](https://help.sap.com/docs/BTP/65de2977205c403bbc107264b8eccf4b/73beb06e127f4e47b849aa95344aabe1.html?locale=en-US) documentation for further information.
@@ -23,16 +40,21 @@ The central point of entry to the platform is the SAP BTP Cockpit (see below), w
> **Hint** - Check the official documentation to learn more ([click here](https://help.sap.com/docs/btp/sap-business-technology-platform/trial-accounts-and-free-tier)).
-Just a few comments on the SAP BTP Account requirements for this use case. You can set up our sample application in any SAP BTP environment using **Free (Tier) service plans** ([click here](https://help.sap.com/docs/btp/sap-business-technology-platform/using-free-service-plans) to learn more) of your own **Pay-as-you-Go** (PAYG) or **CPEA** account ([click here](https://help.sap.com/docs/btp/sap-business-technology-platform/what-is-consumption-based-commercial-model?locale=en-US) to learn more). We highly suggest to create an **Enterprise Account** for the purpose of this and any future use case. While you can set up our sample application also in **Trial** accounts, only an **Enterprise Account** allows you to move from **Free Tier** to **Paid** service plans if required.
+Just a few comments on the SAP BTP Account requirements for this use case. You can set up our sample application in any SAP BTP environment using **Free (Tier) service plans** ([click here](https://help.sap.com/docs/btp/sap-business-technology-platform/using-free-service-plans) to learn more) of your own **Pay-as-you-Go** (PAYG) or **CPEA** account ([click here](https://help.sap.com/docs/btp/sap-business-technology-platform/what-is-consumption-based-commercial-model?locale=en-US) to learn more).
-> **Hint** - A tutorial how to set up a free PAYG account (allowing you to use all Free Tier service plans) can be found in the [Tutorial Navigator](https://developers.sap.com/tutorials/btp-free-tier-account.html).
+We highly suggest to create such an **Enterprise Account** for the purpose of validating this and any future use case. While you can set up our sample application also in **Trial** accounts, only an **Enterprise Account** allows you to move from **Free Tier** to **Paid** service plans if required. Additionally, Trial accounts encompass a few more limitations like a restricted 14 day test period for any new Kyma Cluster.
-**Further links**
+> **Hint** - A tutorial how to set up a **free PAYG account** (allowing you to use all Free Tier service plans) can be found in the [Tutorial Navigator](https://developers.sap.com/tutorials/btp-free-tier-account.html).
+
+**Runtimes**
-Feel free to check out and bookmark the following links for your convenience:
+The key pillars of developing business applications on SAP BTP are the runtimes which can be chosen based on the customer's requirement and expertise. In this scenario, the established **Cloud Foundry Runtime** as well as SAP's managed Kubernetes offering called **Kyma Runtime** will be covered in greater detail below.
-SAP BTP Cockpit (change region if required) 
+
](./images/SaaS_IaaSPaaSSaaS.png?raw=true)
+[
](./images/App_Architecture_Basic_Kyma.png?raw=true)
-**Hint** - As you can see, the two architectures appear similar, still some of the services used in the Cloud Foundry Runtime, are replaced by native Kyma components in the Kubernetes-based architectures.
-This includes e.g., the Credential Store or the Autoscaler, where Kubernetes Secrets or Horizontal Pod Autoscalers are being used. Again, for our **Kubernetes** friends, a more detailed depiction including some of the used Kyma and native Kubernetes components:
+As you can see, the two architectures appear pretty much similar, still some of the services used in the Cloud Foundry Runtime, are replaced by native Kyma components in our Kubernetes-based architectures.
-[
](./images/App_Architecture_BasicDetails.png?raw=true)
+This includes e.g., the Credential Store or the Autoscaler Service, where Kubernetes Secrets or Horizontal Pod Autoscalers are being used. Again, for our **Kubernetes** friends, a more detailed depiction including some of the used Kyma and native Kubernetes components:
+
+[
](./images/App_Sample01.png?raw=true) | [
](./images/App_Sample02.png?raw=true) |
+| [
](./images/App_Sample03.png?raw=true) | [
](./images/App_Sample04.png?raw=true) |
+| [
](./images/App_Sample05.png?raw=true) | [
](./images/App_Sample06.png?raw=true) |
+| [
](./images/App_Sample07.png?raw=true) | [
](./images/App_Sample08.png?raw=true) |
+| [
](./images/App_Sample09.png?raw=true) | [
](./images/App_Sample10.png?raw=true) |
+| [
](./images/App_Sample11.png?raw=true) | [
](./images/App_Sample12.png?raw=true) |
+| [
](./images/App_Sample13.png?raw=true) | [
](./images/App_Sample14.png?raw=true) |
+| [
](./images/App_Sample15.png?raw=true) | [
](./images/App_Sample16.png?raw=true) |
+| [
](./images/App_Sample17.png?raw=true) |
+| [
](./images/Repo_Structure_All.png?raw=true) | 
](./images/Repo_Structure_API.png?raw=true) | **api-service.cds -** CAP-based API Service definition 
](./images/Repo_Structure_App.png?raw=true) | **html5-deployer -** HTML5 Application Deployer configuration 
](./images/Repo_Structure_Broker.png?raw=true) | **package.json -** Node.js dependencies and start script 
](./images/Repo_Structure_Tenant_Db.png?raw=true) | 
](./images/Repo_Structure_Shared_Db.png?raw=true) | **src -** Native SAP HANA database objects 
](./images/Repo_Structure_Router.png?raw=true) | **.dockerignore -** Ignore package.json for docker build 
](./images/Repo_Structure_Service.png?raw=true) | **i18n -** Language files 
](./images/Repo_Structure_API.png?raw=true) | **data -** Sample data for Tenant data model 
](./images/subaccount-delete-error.png?raw=true)
+> **Important** - Please do **not** use the subaccount force-delete option, if there a Service Broker is still registered in the respective subaccount!
+
+[
](./images/Space_TechUser.png?raw=true)
-**Kyma**
-
-For the Kyma environment, this step is not required as no lifecycle events are send by the sample application using the Alert Notification Service.
-
## 5. Limitations of free and trial services plans
diff --git a/docu/2-basic/3-cf-build-deploy-application/README.md b/docu/2-basic/3-cf-build-deploy-application/README.md
index 7432b56..69739b3 100644
--- a/docu/2-basic/3-cf-build-deploy-application/README.md
+++ b/docu/2-basic/3-cf-build-deploy-application/README.md
@@ -1,9 +1,13 @@
# Cloud Foundry - Build and deploy the SaaS application
-**Important - This part of the tutorial is required for Cloud Foundry deployments only!**
+- ### **Kyma** ❌
+- ### **Cloud Foundry** ✅
-Before the deployment of the sample application to your Cloud Foundry environment, you need to build the project and do some basic steps which are required for security purposes.
-After deployment, please make sure that the required credential values are stored in the SAP Credential Store created during deployment.
+
+**Important** - This part of the tutorial is required for **Cloud Foundry** deployments only!
+
+Before the deployment of the sample application to your **Cloud Foundry** environment, you need to build the project and do some basic steps which are required for security purposes.
+**After deployment**, please make sure that the required credential values are stored in the SAP Credential Store created during deployment.
- [Cloud Foundry - Build and deploy the SaaS application](#cloud-foundry---build-and-deploy-the-saas-application)
- [1. Prepare the SaaS Application for deployment](#1-prepare-the-saas-application-for-deployment)
@@ -25,9 +29,11 @@ cd deploy/cf
1.2. Provide a receiver mail address in the **Alert Notification** service configuration file *alert-notif.json* which you can find in the **config** directory.
+> **Hint** - You can also create a *alert-notif-private.json* file or rename the existing file, so your details are not being committed to GitHub.
+
[
](./images/DEPL_EmailNotifSrv.png?raw=true)
-1.3. From the *deploy/cf* directory please execute the following npm scripts to create unique catalog IDs and credentials for your service broker instance.
+1.3. From the *deploy/cf* directory please run the following npm scripts to create unique catalog IDs and credentials for your service broker instance.
```sh
npx --yes -p @sap/sbf hash-broker-password -b
@@ -36,63 +42,41 @@ npx --yes -p @sap/sbf gen-catalog-ids ../../code/broker/catalog.json
1.4. After completing the previous step please note that your unique IDs are added to your */code/broker/catalog.json* and you should see an output similar to the screenshot below. Store the plaintext password for later usage and please copy the hashed credentials which are highlighted below.
-> **Important** - Please make sure to store the hashed credentials and the plaintext password in a secure place especially in a productive scenario that you and also other SAP BTP platform administrators can access at any time! The corresponding user in this scenario is **broker-user**.
+> **Important** - Please make sure to store the hashed credentials and the plaintext password in a secure place especially in a productive scenario. You and also other SAP BTP platform administrators should have access at any time! The corresponding user in this scenario is **broker-user**.
[
](./images/broker-credentials.png?raw=true)
+1.5. To prevent your hashed credentials being committed to GitHub, please first copy the *free-tier.mtaext* or *trial.mtaext* file (depending on your target environment) and add *-private* to the filename (e.g., free-tier-private.mtaext).
-1.5. To prevent your hashed credentials being commited to Git, please first copy the *free-tier.mtaext* or *trial.mtaext* file (depending on your target environment) and add *-private* to the filename (e.g., free-tier-private.mtaext).
-
-> **Important** - Files named *-private.mtaext will be ignorned by Git.
+> **Important** - Files named *-private.mtaext will be ignored by Git.
[
](./images/MTA_DescExt01.png?raw=true)
-1.6. Paste the hashed credentials to the deployment descriptor MTA Extensions file. As explained, we highly recommend to use **private** MTA Extension Descriptors for this purpose which are not being pushed to Git by mistake.
+1.6. Paste the hashed credential value to the **private** deployment descriptor MTA Extensions file you just created. As explained, we highly recommend using **private** MTA Extension Descriptors for this purpose which are not being pushed to Git by mistake.
[
](./images/MTA_DescExt02.png?raw=true)
-Make sure to reference your MTA Extension Descriptor when deploying your application or already reference it during the build process!
+> **Hint** - If you created a private config file for Alert Notification (*anf-config-private.json*), please also include it in your mtaext file accordingly as you can see below!
+> ```yaml
+> resources:
+> - name: susaas-alert-notification
+> parameters:
+> service-plan: standard
+> path: ./config/alert-notif-private.json
+> ```
-**Sample**
-```sh
-$ cf deploy mta_archives/susaas_0.0.1.mtar -e ./mtaext/free-tier-private.mtaext
-```
+1.7. Build your project from the *deploy/cf* directory. Make sure to reference your MTA Extension Descriptor file, either now, when building or later, when deploying your application!
-**or**
+**Sample**
```sh
$ mbt build -e ./mtaext/free-tier-private.mtaext
$ cf deploy mta_archives/susaas_0.0.1.mtar
```
-1.7. Decide if you want to deploy the sample data CSV files with your project. We recommend using the SaaS API to push the respective data after the deployment of the solution.
-
-The sample files provide content for end-to-end testing purposes like **Users**, **Projects**, **Assessments**, **Product** and **Sustainability Data**. This data is supposed to be used for **local development** and **testing scenarios** only. If for any reason you still want to deploy the sample CSV files stored in the [test directory](https://github.com/SAP-samples/btp-cf-cap-multitenant-susaas/tree/basic/test/data), please modify the *before-all* command section of your *build-parameters* in the **mta.yaml** file as follows.
-
-> **Important** - Keep in mind - if you deploy the application incl. sample files, existing table content will be overwritten!
-
-```yaml
-build-parameters:
- before-all:
- - builder: custom
- commands:
- ### Deployment w/o csv sample files ###
- #- npx -p @sap/cds-dk cds build --profile production
-
- ### Deployment w/ csv sample files ###
- - npx -p @sap/cds-dk cds build --profile production,csv
-```
-
-We highly recommend deploying the sample application **without** sample files as this might lead to confusion for your consumers. Instead, please use the SaaS API features if you want to push initial data for **Products** or **Sales Orders** to your consumer tenants. You can find the related documentation in the **Basic Scope** ([click here](../5-push-data-to-saas-api/README.md)).
-
-1.8. Build your project from the *deploy/cf* directory.
-
-```sh
-$ mbt build
-```
-1.9. Please run the command below to deploy the SaaS application to your provider subaccount.
+1.8. Please run the command below to deploy the SaaS application to your provider subaccount. Make sure to reference your MTA Extension Descriptor file, if not done during the build process yet! In that case, you can just skip the additional parameter.
```sh
$ cf deploy mta_archives/
](./images/AN_ConfirmMail.png?raw=true)
-1.11. Once the deployment has finished, you're almost ready to go. To support some automation steps like the creation of routes or deployment of the API Service Broker in the consumer subaccounts, make sure not to miss the next step before settings up your first consumer subaccount.
+1.10. Once the deployment has finished, you're almost ready to go. To support some automation steps like the creation of routes or deployment of the API Service Broker in the consumer subaccounts, make sure not to miss the next step before settings up your first consumer subaccount.
## 2. Setup the Credential Store
Before you learn how to subscribe new tenants in the next part of the mission, you need to provide two credentials in the Credential Store. These credentials are essential for some parts of the automated subscription process.
-2.1. In your provider subaccount, please go to the Instances and Subscriptions menu and click on your **dev-susaas-credstore** instance or use the **Manage Instance** button.
+2.1. In your provider subaccount, please go to the Instances and Subscriptions menu and click on your **\
](./images/CS_Service.png?raw=true)
@@ -159,7 +143,7 @@ As a Username please use the value **broker-user**.
## 3. Troubleshooting
-For troubleshooting please check the separate **Troubleshooting** section of this scope ([click here](../10-troubleshooting/README.md)).
+For troubleshooting please check the separate **Troubleshooting** section ([click here](../10-troubleshooting/README.md)).
## 4. Further information
diff --git a/docu/2-basic/3-kyma-build-docker-images/README.md b/docu/2-basic/3-kyma-build-docker-images/README.md
index 5b3dfbd..4287919 100644
--- a/docu/2-basic/3-kyma-build-docker-images/README.md
+++ b/docu/2-basic/3-kyma-build-docker-images/README.md
@@ -1,6 +1,9 @@
# Kyma - Build, Pack and Push your Docker Images
-**Important - This part of the tutorial is required for Kyma deployments only!**
+- ### **Kyma** ✅
+- ### **Cloud Foundry** ❌
+
+**Important** - This part of the tutorial is required for **Kyma** deployments only!
As you might know, Kubernetes and therefore also Kyma is all about **containerization** of workloads. Our application is no exception from this pattern, so before you can deploy the SaaS sample application to your Kyma Cluster using **Helm**, you first need to build and **containerize** the various components (UI modules, CAP applications, Application Router aso.) by **packing** them into a **Docker Image** and **pushing** this Docker Image to a Container Registry of your choice like e.g., DockerHub. This is what the following chapter will be all about!
@@ -82,32 +85,40 @@ cd deploy/kyma
npm install --include=dev --prefix=../../code
```
+Alternatively, you can also run the following npm script.
+
+```sh
+npm run install
+```
+
2.3. Execute the **cds build --production** command to trigger a new production build of the available CAP components (Shared Data Model, Tenant Data Model, Backend Service, API Service). You can change the version of the package by attaching it with an additional "@"-sign like "@sap/cds-dk@6.8.3".
```sh
npx -p @sap/cds-dk cds build -in ../../code --profile production
```
-> **Important** - If you want to build your project including sample content, you have to run the following command! This should only be done for testing purposes and is not recommended for productive deployments as existing table content will be overwritten!
+Alternatively, you can also run the following npm script.
```sh
-npx -p @sap/cds-dk cds build -in ../../code --profile production,csv
+npm run build
```
-2.3. Build the available UI5 modules by running the following npm command. This will take a few minutes for the first build (as further npm dependencies are installed). Consecutive builds will be much faster.
+2.3. Build the available UI5 modules by running the following npm command. This will take a few minutes for the first build. Consecutive will be faster.
-> **Hint** - This build process, will use the official [UI5 Tools](https://sap.github.io/ui5-tooling/stable/) to build your applications and copies them into the *html5-deployer* directory for deployment.
+> **Hint** - This build process, will use the official [UI5 Tools](https://sap.github.io/ui5-tooling/stable/) to build your applications and copies them into the *code/app/html5-deployer/resources* directory for deployment.
```sh
npm run ui:apps
```
-This is it! The application components requiring a separate **build** step (CAP & UI5) have been catered, and can now be containerized into Docker Images.
+This is it! The application components requiring a separate **build** step (CAP & UI5) have been catered, and can now be containerized into Container Images.
## 3. Create your Docker Images
-While in Cloud Foundry, there is no requirement to containerize your application components before deployment, in Kyma or respectively Kubernetes, you need to take care of this yourself. While this sounds like a complicated effort, we tried to simplify things as much as we can for you! Containerization is required, as during the deployment to your Cluster, Helm will pull the Docker Images of our the sample application components. This includes Docker Image for the following application components:
+While in Cloud Foundry, there is no requirement to containerize your application components before deployment, in Kyma or respectively Kubernetes, you need to take care of this yourself. While this sounds like a complicated effort, we tried to simplify things as much as we can for you!
+
+Containerization is required, as during the deployment to your Cluster, Helm will pull the Docker Images of our the sample application components. This includes Docker Image for the following application components:
- API Service (Pod)
- API Service Broker (Pod)
@@ -120,29 +131,22 @@ These components will be containerized in Docker Images in the following steps.
> **Important** - To learn more about how the Docker Images for the various components are being build, read the next part of this chapter.
-3.1. First of all, open the *package.json* file in the project root (code directory) and update the desired prefix for your Docker Images.
+3.1. Run the following npm script (from within your *deploy/kyma* directory), which will *build* all Docker Images using **SAP Standard Docker Images** and **Cloud Native Buildpacks**.
->**Hint** - If you use e.g. DockerHub as a Container Registry, please put in your **username** (e.g., johndoe) here. If you use the GitHub Container Registry, the prefix will look similar to **ghcr.io/\
](./images/ImageOverview.png?raw=true)
-During Deployment, Helm will generate the required Kubernetes resources (manifest files) based on the provided Helm templates (again - feel free to check out our [Helm Introduction](../8-kyma-resources-helm/README.md)) and deploy them to your Kyma Cluster. This will result in various different objects like **Deployments**, **Jobs** or **SAP BTP Service Instances** or **Bindings**.
+During Deployment, Helm will generate the required Kubernetes resources (*manifest files*) based on the provided Helm templates (again - feel free to check out our [Helm Introduction](../7-kyma-resources-helm/README.md)) and deploy them to your Kyma Cluster. This will result in various different objects like **Deployments**, **Jobs** or **SAP BTP Service Instances** or **Bindings**.
-> **Hint** - To learn more about all the various Kyma and native Kubernetes resources utilized by our sample application, please check out the respective deep-dive chapters ([click here](../8-kyma-resources-helm/README.md))!
+> **Hint** - To learn more about all the various Kyma and native Kubernetes resources utilized by our sample application, please check out the respective deep-dive chapters ([click here](../7-kyma-resources-helm/README.md))!
**Kubernetes Deployments**
@@ -82,9 +85,11 @@ The Helm deployment will create a list of SAP BTP Service Instances and correspo
## 2. Create a new Kyma namespace
-Using Helm, you can deploy the SaaS sample application to either the *default* Kyma namespace or create a new namespace of your choice for this sample application. In the following, you will learn how to create a new namespace called *susaas* in Kyma.
+Using Helm, you can deploy the SaaS sample application to either the *default* Kyma namespace or create a **new namespace** of your choice for this sample application. In the following, you will learn how to create a new namespace called *susaas* in Kyma.
+
+2.1. First of all, please install the [**kubectl**](https://kubernetes.io/docs/tasks/tools/#kubectl) command line tool in your development environment.
-2.1. First of all, please install the [**kubectl**](https://kubernetes.io/docs/tasks/tools/#kubectl) command line tool to your local device. Kubectl allows you to interact with your Kyma Cluster from your command line, as you are used to from any other Kubernetes environment. [Click here](https://kubernetes.io/docs/tasks/tools/#kubectl) to find further information about **kubectl**. Helm will make use of **kubectl** during the deployment process to create the required resources in your Cluster.
+> **Hint** - Kubectl allows you to interact with your Kyma Cluster from your command line, as you are used to from any other Kubernetes environment. [Click here](https://kubernetes.io/docs/tasks/tools/#kubectl) to find further information about **kubectl**. Helm will make use of **kubectl** during the deployment process to create the required resources in your Cluster.
> **Installation Shortcuts**> **MacOS** - brew install kubectl
@@ -93,7 +98,7 @@ Using Helm, you can deploy the SaaS sample application to either the *default* K To learn more about **kubectl** commands check the [official documentation](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands) and the [kubectl cheat sheet](https://kubernetes.io/docs/reference/kubectl/cheatsheet/). Learning how to use **kubectl** is one of the most essential requirements when starting off with Kubernetes and Kyma. The command syntax is quite simple to understand and follows a consistent pattern. So don't shy to have a little deep-dive into the provided documentations. It pays! -2.2. Before you continue with the next step, make sure you can successfully execute the following command. This proves that kubectl has been successfully added to your Environment Variables. In case of errors, please try again from a new command line instance and make sure you followed all steps in the installation instructions provided. +2.2. Before you continue with the next step, make sure you can successfully execute the following command. This proves that kubectl has been successfully added to your Environment Variables. In case of errors, please try again from a new command line instance and make sure you followed all steps of the kubectl installation instructions. ```sh > kubectl version @@ -115,7 +120,7 @@ Check the successful installation by running the following command. kubelogin version v1.26.0 ``` -2.4. Download the so-called **kubeconfig** file associated to your Kyma Cluster from your SAP BTP Cockpit. You can find it in your SAP BTP subaccount **Overview** section. This file contains all the required access details and credentials so that **kubectl** can connect to your Kyma Cluster. +2.4. Download the so-called **kubeconfig** file of your Kyma Cluster from your SAP BTP Cockpit. You can find it in your SAP BTP subaccount **Overview** section. This file contains all required access details and credentials so that **kubectl** can connect to your Kyma Cluster. > **Important** - Do not share this file with anyone else and do not commit it to your GitHub repository. @@ -134,9 +139,7 @@ EXPORT KUBECONFIG=/sample/path/config kubectl get pods --kubeconfig=/sample/path/config ``` -If you are facing issues in this step of the tutorial, feel free to consult the excellent **Developer Tutorial** on **Deploy Your CAP Application on SAP BTP Kyma Runtime**, which describes this step in further detail! - -https://developers.sap.com/tutorials/btp-app-kyma-prepare-dev-environment.html +If you are facing issues in this step of the tutorial, feel free to consult the excellent **Developer Tutorial** on **Deploy Your CAP Application on SAP BTP Kyma Runtime** ([click here](https://developers.sap.com/tutorials/btp-app-kyma-prepare-dev-environment.html)), which describes this step in further detail! > **Hint** - If you have to manage multiple Kyma or Kubernetes Clusters, make sure to research the **kubectx** command line tool (https://github.com/ahmetb/kubectx)! It provides you a very convenient way to switch the context between various clusters. @@ -150,9 +153,9 @@ https://developers.sap.com/tutorials/btp-app-kyma-prepare-dev-environment.html Kubernetes control plane is running at https://api.a1b2c3d4.kyma.ondemand.com ``` -2.7. The following command, finally allows you to create a new namespace in your Kyma cluster. To learn more about **kubectl** commands check the [official documentation](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands) and the [kubectl cheat sheet](https://kubernetes.io/docs/reference/kubectl/cheatsheet/). +2.7. The following kubectl command, finally allows you to create a new namespace in your Kyma cluster. To learn more about **kubectl** commands check the [official documentation](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands) and the [kubectl cheat sheet](https://kubernetes.io/docs/reference/kubectl/cheatsheet/). -> **Hint** - This is just a sample for your reference. If you want, you can deploy the sample application also to the Kyma *default* namespace or any other namespace of your choice! +> **Hint** - This is just a sample for your reference. If you want, you can deploy the sample application also to the Kyma *default* namespace or any other namespace of your choice! Just make sure to adapt the sample commands provided in this documentation accordingly. ```sh > kubectl create namespace susaas @@ -160,7 +163,9 @@ Kubernetes control plane is running at https://api.a1b2c3d4.kyma.ondemand.com namespace/susaas created ``` -2.8. Use the following command, to enable the **Istio** Sidecar Injection for your new namespace. **Istio** is one of the most popular **Service Mesh** offerings for Kubernetes and manages Cluster-internal communication as well as external access to your workloads! We highly recommend to learn more about [**Istio Service Mesh**](../8-kyma-resources-helm/README.md), by visiting the respective part of the tutorial. The features and possibilities are mind-blowing compared to what you can do in a Cloud Foundry scenario! +2.8. Use the following command, to enable the **Istio** Sidecar Injection for your new namespace. + +> **Hint** - **Istio** is one of the most popular **Service Mesh** offerings for Kubernetes and manages Cluster-internal communication as well as external access to your workloads! We highly recommend to learn more about [**Istio Service Mesh**](../8-kyma-resources-helm/README.md), by visiting the respective part of the tutorial. The features and possibilities are mind-blowing compared to what you can do in a Cloud Foundry scenario! > **Important** - If you plan to use an existing namespace, make sure this label is configured and if necessary, please update the namespace using **kubectl** or the Kyma Dashboard! @@ -168,9 +173,9 @@ namespace/susaas created kubectl label namespace susaas istio-injection=enabled ``` -You can either use **kubectl** or check in you Kyma Dashboard, whether the label has been successfully set! +You can either use **kubectl** or check in your Kyma Dashboard, whether the respective label has been successfully set! -> **Hint** - Here you can see another kubectl command called **describe**, giving you more information (than a pure **get**) about a certain object like in this case our namespace. +> **Hint** - Here you can see another kubectl command called **describe**, providing you more information (than a simple **get**) about a certain object like in this case a namespace. ```sh > kubectl describe namespace susaas @@ -185,7 +190,7 @@ Labels: istio-injection=enabled 2.9. To delete a namespace, just execute the following **kubectl** command. Already getting an idea about how the kubectl commands are structured? Great! -> **Important** - Be **extremely cautious** when deleting a namespace containing a **SaaS application** with **active subscribers**. This can result in very cumbersome situations, where SAP BTP Service Instances like XSUAA can only be deleted with complex additional effort. Before you **delete a namespace** or **uninstall a Helm Release**, always make sure there are no more active subscribers! +> **Important** - Be **extremely sensitive** when deleting a namespace containing a **SaaS application** with **active subscribers**. This can result in very situations, where SAP BTP Service Instances like XSUAA can only be deleted with complex additional effort. Before you **delete a namespace** or **uninstall a Helm Release**, always make sure there are no more active subscribers! ```sh > kubectl delete namespace susaas @@ -200,9 +205,11 @@ Okay great, by now you should be equipped with either a new namespace or the def Let's get started with the preparation of our **Helm deployment** or **Helm installation**. Based on your own Kyma environment, you will need to update the *values.yaml* file of your **Umbrella Chart**. This is a regular process step, which you need to undertake as part of almost any Helm installation to inject environment-specific details which cannot be pre-configured by the application/package vendor. -3.1. Open the Umbrella Chart *values.yaml* file (of our SaaS sample application) in the *code/charts/sustainable-saas* directory ([click here](../../../code/charts/sustainable-saas/values.yaml)). +3.1. Either copy or rename the Umbrella Chart *values.yaml* file (of our SaaS sample application) in the *deploy/kyma/charts/sustainable-saas* directory ([click here](../../../deploy/kyma/charts/sustainable-saas/values.yaml)) and add **-private** as part of the filename *values-private.yaml* -3.2. Provide values for the following parameters, based on your own environment and the Container Registry used. +> **Important** - By adding **-private** to the filename, no confidential or environment specific details will be committed to Git, as these files will be ignored by Git. + +3.2. In the **values-private.yaml** file, please provide values for the following parameters, based on your own environment and the Container Registry used. **global** @@ -241,50 +248,31 @@ Let's get started with the preparation of our **Helm deployment** or **Helm inst * image.repository - Provide the details of your [Application Router](../3-build-your-docker-images/) Docker Image like \
+ > ```npx --yes -p @sap/sbf gen-catalog-ids ../../code/broker/catalog.json ``` **hana_deployer** -* image.repository - Provide the details of your [HDI Container Deployer](../3-build-your-docker-images/) Docker Image repository like \
+e.g., subscriber-c3b2a1-susaas-router-default.a1b2c3.kyma.ondemand.com While this may result in long and inconvenient URLs for your subscribers, the uniqueness of the generated subdomain is ensured when following this format. If you decide to provide a custom subdomain, the resulting URL will have the following format (as long as you are not using a custom domain). -**\
+e.g., subscriber.a1b2c3.kyma.ondemand.com In this sample, we did not implement a check for the uniqueness of the value provided. It is in your responsibility to ensure, not to double-assign the same custom subdomain to your subscribers! diff --git a/docu/2-basic/5-push-data-to-saas-api/README.md b/docu/2-basic/5-push-data-to-saas-api/README.md index fe2d8b9..1b039f5 100644 --- a/docu/2-basic/5-push-data-to-saas-api/README.md +++ b/docu/2-basic/5-push-data-to-saas-api/README.md @@ -1,5 +1,8 @@ # Push data to the SaaS API +- ### **Kyma** ✅ +- ### **Cloud Foundry** ✅ + The SaaS sample application is equipped with a built-in SaaS API, that your subscribers can use, to push data to their Tenant database containers or to modify existing data. In this part of the tutorial, you will learn how to connect to this API endpoint as a SaaS Tenant and push some sample data. - [Push data to the SaaS API](#push-data-to-the-saas-api) diff --git a/docu/2-basic/6-test-the-application/README.md b/docu/2-basic/6-test-the-application/README.md index 33a0033..48fb6a6 100644 --- a/docu/2-basic/6-test-the-application/README.md +++ b/docu/2-basic/6-test-the-application/README.md @@ -1,5 +1,8 @@ # Test the application +- ### **Kyma** ✅ +- ### **Cloud Foundry** ✅ + In this part of the tutorial (since you have already subscribed to the application) you will get some guidance on how to test the SaaS sample application from a Consumer perspective. - [Test the application](#test-the-application) diff --git a/docu/2-basic/7-explore-the-components/README.md b/docu/2-basic/7-explore-the-components/README.md index ff5f781..87b512d 100644 --- a/docu/2-basic/7-explore-the-components/README.md +++ b/docu/2-basic/7-explore-the-components/README.md @@ -1,5 +1,8 @@ # Explore the application components +- ### **Kyma** ✅ +- ### **Cloud Foundry** ✅ + After you have deployed the sample application the following components will be available in the Cloud Foundry environment or respectively the Kyma Cluster of your SAP BTP Provider Subaccount. - [Explore the application components](#explore-the-application-components) diff --git a/docu/2-basic/7-explore-the-components/components/HelperClasses.md b/docu/2-basic/7-explore-the-components/components/HelperClasses.md index e86986d..019204f 100644 --- a/docu/2-basic/7-explore-the-components/components/HelperClasses.md +++ b/docu/2-basic/7-explore-the-components/components/HelperClasses.md @@ -1,5 +1,8 @@ # Deep Dive into Helper Classes +- ### **Kyma** ✅ +- ### **Cloud Foundry** ✅ + In this part of the tutorial, you will learn about the different helper classes implemented in the business application service. These classes mainly support the automation of the Tenant subscription process. Furthermore, they contain the logic of the in-app user management. - [Deep Dive into Helper Classes](#deep-dive-into-helper-classes) @@ -22,30 +25,54 @@ The table below shows all helper classes used by the Sustainable SaaS business a | Util | Source Code | Description | | ------------- | -------------------------- | --------------------------------------------------------------------- | -| [Automator](#2-Automator) | [automator.js](https://github.com/SAP-samples/btp-cap-multitenant-saas/blob/main/code/srv/utils/automator.js)| Helper class for automatic creation and deletion of artifacts on Tenant (un-)subscription | -| [Cloud-Management-Helper](#3-Cloud-Management-Helper) | [cis-central.js](https://github.com/SAP-samples/btp-cap-multitenant-saas/blob/main/code/srv/utils/cis-central.js) | Helper class interacting with Cloud Management Service (central plan) | -| [Service-Manager-Helper](#4-Service-Manager-Helper) | [service-manager.js](https://github.com/SAP-samples/btp-cap-multitenant-saas/blob/main/code/srv/utils/service-manager.js) | Helper class interacting with Service Manager Subaccount (admin plan) | -| [Token-Helper](#5-Token-Helper) | [token-utils.js](https://github.com/SAP-samples/btp-cap-multitenant-saas/blob/main/code/srv/utils/token-utils.js) | Helper class retrieving tokens from relevant OAuth2 servers | -| [Destination-Helper](#6-Destination-Helper) | [destination.js](https://github.com/SAP-samples/btp-cap-multitenant-saas/blob/main/code/srv/utils/destination.js) | Helper module interacting with the SAP Destination Service | -| [Credential-Store-Helper](#7-Credential-Store-Helper) | [credStore.js](https://github.com/SAP-samples/btp-cap-multitenant-saas/blob/main/code/srv/utils/credStore.js) | Helper module interacting with the SAP Credential Store when using Cloud Foundry | -| [User-Management-Helper](#8-User-Management-Helper) | [user-management.js](https://github.com/SAP-samples/btp-cap-multitenant-saas/blob/main/code/srv/utils/user-management-utils.js) | Helper class for User and Role management interacting with SAP Identity Authentication and XSUAA | -| [Alert-Notification-Helper](#9-Alert-Notification-Helper) | [alertNotification.js](https://github.com/SAP-samples/btp-cap-multitenant-saas/blob/main/code/srv/utils/alertNotification.js) | Helper class for interacting with SAP Alert Notification service | -| [Kyma-Utils](#10-Kyma-Utils) | [kyma-utils.js](https://github.com/SAP-samples/btp-cap-multitenant-saas/blob/main/code/srv/utils/kyma-utils.js) | Helper module interacting with the SAP Kyma Runtime API (e.g., to create API Rules) | -| [Cloud-Foundry-Utils](#10-Cloud-Foundry-Utils) | [cf-utils.js](https://github.com/SAP-samples/btp-cap-multitenant-saas/blob/main/code/srv/utils/cf-utils.js) | Helper module interacting with the Cloud Foundry API (e.g., to create routes) | +| [Automator](#2-Automator) | [automator.js](https://github.com/SAP-samples/btp-cap-multitenant-saas/blob/main/code/srv/srv/utils/automator.js)| Runtime-specific helper classes for automatic creation and deletion of artifacts on Tenant (un-)subscription | +| [Cloud-Management-Helper](#3-Cloud-Management-Helper) | [cis-central.js](https://github.com/SAP-samples/btp-cap-multitenant-saas/blob/main/code/srv/srv/utils/cis-central.js) | Helper class interacting with Cloud Management Service (central plan) | +| [Service-Manager-Helper](#4-Service-Manager-Helper) | [service-manager.js](https://github.com/SAP-samples/btp-cap-multitenant-saas/blob/main/code/srv/srv/utils/service-manager.js) | Helper class interacting with Service Manager Subaccount (admin plan) | +| [Token-Helper](#5-Token-Helper) | [token-utils.js](https://github.com/SAP-samples/btp-cap-multitenant-saas/blob/main/code/srv/srv/utils/token-utils.js) | Helper class retrieving tokens from relevant OAuth2 servers | +| [Destination-Helper](#6-Destination-Helper) | [destination.js](https://github.com/SAP-samples/btp-cap-multitenant-saas/blob/main/code/srv/srv/utils/destination.js) | Helper module interacting with the SAP Destination Service | +| [Credential-Store-Helper](#7-Credential-Store-Helper) | [credStore.js](https://github.com/SAP-samples/btp-cap-multitenant-saas/blob/main/code/srv/srv/utils/credStore.js) | Helper module interacting with the SAP Credential Store when using Cloud Foundry | +| [User-Management-Helper](#8-User-Management-Helper) | [user-management.js](https://github.com/SAP-samples/btp-cap-multitenant-saas/blob/main/code/srv/srv/utils/user-management-utils.js) | Helper class for User and Role management interacting with SAP Identity Authentication and XSUAA | +| [Alert-Notification-Helper](#9-Alert-Notification-Helper) | [alertNotification.js](https://github.com/SAP-samples/btp-cap-multitenant-saas/blob/main/code/srv/srv/utils/alertNotification.js) | Helper class for interacting with SAP Alert Notification service | +| [Kyma-Utils](#10-Kyma-Utils) | [kyma-utils.js](https://github.com/SAP-samples/btp-cap-multitenant-saas/blob/main/code/srv/srv/utils/kyma-utils.js) | Helper module interacting with the SAP Kyma Runtime API (e.g., to create Kyma API Rules) | +| [Cloud-Foundry-Utils](#10-Cloud-Foundry-Utils) | [cf-utils.js](https://github.com/SAP-samples/btp-cap-multitenant-saas/blob/main/code/srv/srv/utils/cf-utils.js) | Helper module interacting with the Cloud Foundry API (e.g., to create Cloud Foundry Routes) | ## 2. Automator (automator.js) -For effortless Tenant on-offboarding in the SaaS context, it is essential to automate the process of onboarding as much as it can be automated. Therefore, the sample application automates as many steps as possible during the subscription of the SaaS Tenant instance. The [Automator](https://github.com/SAP-samples/btp-cap-multitenant-saas/blob/main/code/srv/utils/automator.js) module helps to provide a fully automated, self-service (un-) subscription experience. - -The Automator is responsible for the following topics: -- Creation of destinations in a **Consumer Subaccount** on subscription with the help of [destination.js](https://github.com/SAP-samples/btp-cap-multitenant-saas/blob/main/code/srv/utils/destination.js). -- Deletion of destinations from **Consumer Subaccount** on unsubscription with the help of [destination.js](https://github.com/SAP-samples/btp-cap-multitenant-saas/blob/main/code/srv/utils/destination.js). -- Creation of a Cloud Management service instance & binding within the **Provider Subaccount** [cis-central.js](https://github.com/SAP-samples/btp-cap-multitenant-saas/blob/main/code/srv/utils/cis-central.js) -- Deletion of a Cloud Management service instance & binding from the **Provider Subaccount** [cis-central.js](https://github.com/SAP-samples/btp-cap-multitenant-saas/blob/main/code/srv/utils/cis-central.js) -- Creation of a service manager service instance & binding within a **Consumer Subaccount** with the help of [cis-central.js](https://github.com/SAP-samples/btp-cap-multitenant-saas/blob/main/code/srv/utils/cis-central.js). -- Deletion of a service manager service instance & binding from a **Consumer Subaccount** with the help of [cis-central.js](https://github.com/SAP-samples/btp-cap-multitenant-saas/blob/main/code/srv/utils/cis-central.js). -- Registering of a service broker in a **Consumer Subaccount** on subscription with the help of [service-manager.js](https://github.com/SAP-samples/btp-cap-multitenant-saas/blob/main/code/srv/utils/service-manager.js). -- Unregistering of a service broker from a **Consumer Subaccount** on unsubscription with the help of [service-manager.js](https://github.com/SAP-samples/btp-cap-multitenant-saas/blob/main/code/srv/utils/service-manager.js). + +For effortless Tenant on-offboarding in the SaaS context, it is essential to automate the process of onboarding as much as it can be automated. Therefore, the sample application automates as many steps as possible during the subscription of the SaaS Tenant instance. The [Automator](https://github.com/SAP-samples/btp-cap-multitenant-saas/blob/main/code/srv/srv/utils/automator.js) module helps to provide a fully automated, self-service (un-) subscription experience. + +As a few steps of the automation process are runtime dependent, the respective module is returning different Java Script Classes, which are overwriting and extending a TenantAutomator Base Class. While most automation steps are congruent for the **Kyma** and **Cloud Foundry Runtime** and can be handled by the Base Class implementation, the runtime-specific Classes take care of specific configurations like setting up API Rules (in Kyma) or Routes (in Cloud Foundry). + +```js +// Shared logic +class TenantAutomator +// Runtime-specific extensions and overwrites +class CloudFoundry extends TenantAutomator +class Kyma extends TenantAutomator +... +// Module returns runtime-specific Class +export default (process.env.VCAP_APPLICATION ? CloudFoundry : Kyma) +``` + +The Automator is responsible for the following tasks: + +- Creation of destinations in a **Consumer Subaccount** on subscription with the help of [destination.js](https://github.com/SAP-samples/btp-cap-multitenant-saas/blob/main/code/srv/srv/utils/destination.js). +- Deletion of destinations from **Consumer Subaccount** on unsubscription with the help of [destination.js](https://github.com/SAP-samples/btp-cap-multitenant-saas/blob/main/code/srv/srv/utils/destination.js). +- Creation of a Cloud Management service instance & binding within the **Provider Subaccount** [cis-central.js](https://github.com/SAP-samples/btp-cap-multitenant-saas/blob/main/code/srv/srv/utils/cis-central.js) +- Deletion of a Cloud Management service instance & binding from the **Provider Subaccount** [cis-central.js](https://github.com/SAP-samples/btp-cap-multitenant-saas/blob/main/code/srv/srv/utils/cis-central.js) +- Creation of a service manager service instance & binding within a **Consumer Subaccount** with the help of [cis-central.js](https://github.com/SAP-samples/btp-cap-multitenant-saas/blob/main/code/srv/srv/utils/cis-central.js). +- Deletion of a service manager service instance & binding from a **Consumer Subaccount** with the help of [cis-central.js](https://github.com/SAP-samples/btp-cap-multitenant-saas/blob/main/code/srv/srv/utils/cis-central.js). +- Registering of a service broker in a **Consumer Subaccount** on subscription with the help of [service-manager.js](https://github.com/SAP-samples/btp-cap-multitenant-saas/blob/main/code/srv/srv/utils/service-manager.js). +- Unregistering of a service broker from a **Consumer Subaccount** on unsubscription with the help of [service-manager.js](https://github.com/SAP-samples/btp-cap-multitenant-saas/blob/main/code/srv/srv/utils/service-manager.js). + + **Kyma** + - Creation of new API Rules for the respective Consumer Subaccount during subscription with the help of [kyma-utils.js](https://github.com/SAP-samples/btp-cap-multitenant-saas/blob/main/code/srv/srv/utils/kyma-utils.js). + - Deletion of existing API Rules for the respective Subaccount during unsubscription with the help of [kyma-utils.js](https://github.com/SAP-samples/btp-cap-multitenant-saas/blob/main/code/srv/srv/utils/kyma-utils.js). + + **Cloud Foundry** + - Creation of new Routes for the respective Consumer Subaccount during subscription with the help of [cf-utils.js](https://github.com/SAP-samples/btp-cap-multitenant-saas/blob/main/code/srv/srv/utils/cf-utils.js). + - Deletion of existing Routes for the respective Subaccount during unsubscription with the help of [cf-utils.js](https://github.com/SAP-samples/btp-cap-multitenant-saas/blob/main/code/srv/srv/utils/cf-utils.js). + When a Tenant **subscribes** to the Sustainable SaaS app, 1. A new Cloud Management Service instance (central plan) will be created in the **Provider Subaccount**. @@ -54,6 +81,12 @@ When a Tenant **subscribes** to the Sustainable SaaS app, 4. A sample destination called **\*_S4HANA_CLOUD** will be created in the **Consumer Subaccount**. 5. The Service Manager instance created in step 2 will be deleted from the **Consumer Subaccount** again. 6. The Cloud Management Service instance created in step 1 will be deleted from the **Provider Subaccount** again. + + **Kyma** + - A new API Rule will be created for the new Consumer Subaccount. + + **Cloud Foundry** + - A new Cloud Foundry Route will be created for the new Consumer Subaccount (not required when using a custom domain). When a Tenant **unsubscribes** from the Sustainable SaaS app, 1. A new Cloud Management Service instance (central plan) will be created in the **Provider Subaccount**. @@ -62,6 +95,12 @@ When a Tenant **unsubscribes** from the Sustainable SaaS app, 4. The **\*_S4HANA_CLOUD** destination will be deleted from the **Consumer Subaccount**. 5. The Service Manager instance created in Step 2 will be deleted from the **Consumer Subaccount**. 6. The Cloud Management Service instance created in step 1 will be deleted again from the **Provider Subaccount**. + + **Kyma** + - The API Rule of the Consumer Subaccount triggering the **Unsubscription** will be removed. + + **Cloud Foundry** + - The Cloud Foundry Route of the Consumer Subaccount triggering the **Unsubscription** will be removed (not required when using a custom domain). ## 3. Cloud Management Helper (cis-central.js) @@ -78,17 +117,17 @@ Service Manager (subaccount admin plan) in Provider Subaccount **creates** Service Manager (subaccount admin plan) in Consumer Subaccount **registers** API Service Broker (in Consumer Subaccount) -> **Hint** - The default Service Manager used by Kyma (plan service-operator-access) cannot be used to create such an instance! +> **Hint** - The default Service Manager instance used by the SAP BTP Service Operator in Kyma (plan service-operator-access) cannot be used to create such an instance! ## 4. Service Manager Helper (service-manager.js) The Service Manager is a central registry for service brokers and platforms. It tracks service instances creation and allows sharing of services and service instances between different platform instances. The Service Manager allows an application to use services and service instances of multiple platforms. -The [Service Manager helper](https://github.com/SAP-samples/btp-cap-multitenant-saas/blob/main/code/srv/utils/service-manager.js) module is used for (un-)registering the custom API Service Broker in the Sustainable SaaS App context by interacting with the [Service Manager service instance](https://api.sap.com/api/APIServiceManagment/overview), created in the Consumer Subaccount by the Cloud Management Service (central plan). +The [Service Manager helper](https://github.com/SAP-samples/btp-cap-multitenant-saas/blob/main/code/srv/srv/utils/service-manager.js) module is used for (un-)registering the custom API Service Broker in the Sustainable SaaS App context by interacting with the [Service Manager service instance](https://api.sap.com/api/APIServiceManagment/overview), created in the Consumer Subaccount by the Cloud Management Service (central plan). ## 5. Token Helper (token-utils.js) -The [Token helper](https://github.com/SAP-samples/btp-cap-multitenant-saas/blob/main/code/srv/utils/token-utils.js) module is used for retrieving tokens from OAuth2 servers using the client credentials type. +The [Token helper](https://github.com/SAP-samples/btp-cap-multitenant-saas/blob/main/code/srv/srv/utils/token-utils.js) module is used for retrieving tokens from OAuth2 servers using the client credentials flow. ## 6. Destination Helper (destination.js) @@ -96,11 +135,11 @@ The [Destination helper](./destination.js) is used for retrieving, creating, and ## 7. Credential Store Helper (credStore.js) -The [Credential Store helper](https://github.com/SAP-samples/btp-cf-cap-multitenant-susaas/blob/basic/srv/utils/credStore.js) module is used to interact with the [SAP Credential Store](https://api.sap.com/package/CredentialStore/rest) service in the provider subaccount and is being used as part of the **Cloud Foundry** based scenario. In the Kyma scenario, Kubernetes Secrets are used instead. +The [Credential Store helper](https://github.com/SAP-samples/btp-cf-cap-multitenant-susaas/blob/main/code/srv/srv/utils/credStore.js) module is used to interact with the [SAP Credential Store](https://api.sap.com/package/CredentialStore/rest) service in the provider subaccount and is being used as part of the **Cloud Foundry** based scenario. In the Kyma scenario, Kubernetes Secrets are used instead. ## 8. User Management Helper (user-management.js) -The [User Management helper](https://github.com/SAP-samples/btp-cap-multitenant-saas/blob/main/code/srv/utils/user-management.js) module is used for handling users and role assignments in both SAP IAS and XSUAA. For this use-case, it is required to allow in-app user management for SaaS Consumers. +The [User Management helper](https://github.com/SAP-samples/btp-cap-multitenant-saas/blob/main/code/srv/srv/utils/user-management.js) module is used for handling users and role assignments in both SAP IAS and XSUAA. For this use-case, it is required to allow in-app user management for SaaS Consumers. **Requirements** 1. A Tenant administrator should be able to create users without accessing the SAP BTP Consumer Subaccount. @@ -121,17 +160,17 @@ To be able to provide this functionality, the User-Management-Helper interacts w ## 9. Alert Notification Helper (alertNotification.js) -The [Alert Notification helper](https://github.com/SAP-samples/btp-cap-multitenant-saas/blob/main/code/srv/utils/alertNotification.js) helper is used to interact with the SAP BTP Alert Notification Service. In this sample, the provided functions allow you to send a generic notification to recipients of the event. +The [Alert Notification helper](https://github.com/SAP-samples/btp-cap-multitenant-saas/blob/main/code/srv/srv/utils/alertNotification.js) helper is used to interact with the SAP BTP Alert Notification Service. In this sample, the provided functions allow you to send a generic notification to recipients of the event. ## 10. Kyma Utils (kyma-utils.js) -The [Kyma utilities](./kyma-utils.js) are used during subscription, to create new API Rules in the Kyma Cluster. These API rules expose a dedicated host for each Subscriber like **customer.c-a1b2c3.kyma.ondemand.com** if a custom value is provided during the subscription process. If the subscription does not require a custom domain, the default host pattern incl. the Consumer subaccount subdomain will be used like **customer-379a13f-susaas-router-susaas.c-a1b2c3.kyma.ondemand.com**. +The [Kyma utilities](https://github.com/SAP-samples/btp-cap-multitenant-saas/blob/main/code/srv/srv/utils/kyma-utils.js) are used during subscription, to create new API Rules in the Kyma Cluster. These API rules expose a dedicated host for each Subscriber like **customer.c-a1b2c3.kyma.ondemand.com** if a custom value is provided during the subscription process. If the subscription does not require a custom domain, the default host pattern incl. the Consumer subaccount subdomain will be used like **customer-379a13f-susaas-router-susaas.c-a1b2c3.kyma.ondemand.com**. >**Hint** - If you are using a custom domain, the result will include your custom domain instead of **c-a1b2c3.kyma.ondemand.com**. ## 11. Cloud Foundry Utils (cf-utils.js) -The [Cloud Foundry utilities](./cf-utils.js) are used during subscription, to create new Cloud Foundry routes. These routes expose a dedicated host for each Subscriber like like **customer-379a13f-susaas-router-susaas.cfapps.eu10.hana.ondemand.com**. Using a custom domain or dedicated hostname defined during the subscription process is (as of today) not possible. To fulfill this requirement, the usage of the **SAP Custom Domain Service** is essential. To learn more, please check the respective expert features. +The [Cloud Foundry utilities](https://github.com/SAP-samples/btp-cap-multitenant-saas/blob/main/code/srv/srv/utils/cf-utils.js) are used during subscription, to create new Cloud Foundry routes. These routes expose a dedicated host for each Subscriber like like **customer-379a13f-susaas-router-susaas.cfapps.eu10.hana.ondemand.com**. Using a custom domain or dedicated hostname defined during the subscription process is (as of today) not possible. To fulfill this requirement, the usage of the **SAP Custom Domain Service** is essential. To learn more, please check the respective expert features. >**Hint** - If you are using a custom domain, the result will include your custom domain instead of **cfapps.eu10.hana.ondemand.com***. diff --git a/docu/2-basic/7-explore-the-components/components/Multitenancy.md b/docu/2-basic/7-explore-the-components/components/Multitenancy.md index 2d45dd8..8d4c979 100644 --- a/docu/2-basic/7-explore-the-components/components/Multitenancy.md +++ b/docu/2-basic/7-explore-the-components/components/Multitenancy.md @@ -1,5 +1,8 @@ # Deep Dive into Multitenancy +- ### **Kyma** ✅ +- ### **Cloud Foundry** ✅ + In this part of the tutorial, you will learn about different aspects of multitenancy and how tenants are handled by the SaaS application. - [Deep Dive into Multitenancy](#deep-dive-into-multitenancy) diff --git a/docu/2-basic/7-explore-the-components/components/ServiceBrokers.md b/docu/2-basic/7-explore-the-components/components/ServiceBrokers.md index 88cb2c4..d8bc5ab 100644 --- a/docu/2-basic/7-explore-the-components/components/ServiceBrokers.md +++ b/docu/2-basic/7-explore-the-components/components/ServiceBrokers.md @@ -1,5 +1,8 @@ # Deep Dive into Service Brokers +- ### **Kyma** ✅ +- ### **Cloud Foundry** ✅ + This part of the tutorial will explain the details of the SaaS API backing service implementation together with a dedicated service broker since both components are working hand in hand to provide a multitenant SaaS API. - [Deep Dive into Service Brokers](#deep-dive-into-service-brokers) diff --git a/docu/2-basic/7-explore-the-components/components/SharedContainer.md b/docu/2-basic/7-explore-the-components/components/SharedContainer.md index 611540d..ec0025b 100644 --- a/docu/2-basic/7-explore-the-components/components/SharedContainer.md +++ b/docu/2-basic/7-explore-the-components/components/SharedContainer.md @@ -1,5 +1,8 @@ # Shared Database Container +- ### **Kyma** ✅ +- ### **Cloud Foundry** ✅ + To have the ability to share data among your Consumer tenants, a shared database container is set up for this sample scenario. This allows you as a Provider to maintain e.g., master data in a central place and update it simultaneously for all Consumer tenants. - [Shared Database Container](#shared-database-container) diff --git a/docu/2-basic/7-kyma-resources-helm/README.md b/docu/2-basic/7-kyma-resources-helm/README.md index b0211fc..c4d70e0 100644 --- a/docu/2-basic/7-kyma-resources-helm/README.md +++ b/docu/2-basic/7-kyma-resources-helm/README.md @@ -1,5 +1,8 @@ # Helm Charts and Kyma resources +- ### **Kyma** ✅ +- ### **Cloud Foundry** ❌ + While our next chapter will focus on the functional perspective of the different application components like Multitenancy in Application Router, this chapter will give you a deep-dive into the resources and technology used for the deployment of our sample scenario. For your convenience and a better structure, this chapter has been split up into three parts. - [Helm Charts and Kyma resources](#helm-charts-and-kyma-resources) diff --git a/docu/2-basic/7-kyma-resources-helm/components/HelmCharts.md b/docu/2-basic/7-kyma-resources-helm/components/HelmCharts.md index 008a71d..09fbe07 100644 --- a/docu/2-basic/7-kyma-resources-helm/components/HelmCharts.md +++ b/docu/2-basic/7-kyma-resources-helm/components/HelmCharts.md @@ -1,5 +1,8 @@ # Helm Charts +- ### **Kyma** ✅ +- ### **Cloud Foundry** ❌ + This part of the tutorial contains a brief documentation on the topic of Helm and how it is being used in the context of our Sustainable SaaS sample application. Helm is an extremely powerful tool set simplifying the automated definition of Kubernetes/Kyma resources and the subsequent deployment to your Cluster. Given the sheer complexity of Helm, this tutorial will only cover certain basic aspects that will simplify starting your own learning journey. Once you start adapting the templates based on your own needs, there will be no shortcut but a deep-dive into the official documentation is inevitable. diff --git a/docu/2-basic/7-kyma-resources-helm/components/ResourceOverview.md b/docu/2-basic/7-kyma-resources-helm/components/ResourceOverview.md index a15ad18..87a7a35 100644 --- a/docu/2-basic/7-kyma-resources-helm/components/ResourceOverview.md +++ b/docu/2-basic/7-kyma-resources-helm/components/ResourceOverview.md @@ -1,5 +1,8 @@ # Resource Overview +- ### **Kyma** ✅ +- ### **Cloud Foundry** ❌ + This SaaS sample application makes use of various Kubernetes as well as custom Kyma resource definitions. In this chapter, you will get a brief introduction to the various resources and links where to find further valuable information if required. While you can find comprehensive details for all of these resources online, in this part of the tutorial, we try to explain the purpose of the components in relation to the given scenario - using our own words. So please understand, that our explanations might not necessarily match the official documentation content for all resources. If you find any inconsistencies, feel free to provide adjustments or recommendations using a pull request. diff --git a/docu/2-basic/7-kyma-resources-helm/components/TemplateDetails.md b/docu/2-basic/7-kyma-resources-helm/components/TemplateDetails.md index 66aca14..4f1a10d 100644 --- a/docu/2-basic/7-kyma-resources-helm/components/TemplateDetails.md +++ b/docu/2-basic/7-kyma-resources-helm/components/TemplateDetails.md @@ -1,5 +1,8 @@ # Template Details +- ### **Kyma** ✅ +- ### **Cloud Foundry** ❌ + This chapter provides detailed information on the various Helm templates and corresponding Kyma and Kubernetes resources. If you are new to Helm and have not checked out the provided introduction yet, we strongly recommend to read the respective [Helm Charts](./HelmCharts.md) chapter first. While the subsequent [Resource Overview](./ResourceOverview.md) chapter describes the general purpose of the different Kyma and Kubernetes resource types, in this part of the tutorial, we cover the scenario-related usage of the various components. - [Template Details](#template-details) diff --git a/docu/2-basic/8-unsubscribe-consumer-subaccount/README.md b/docu/2-basic/8-unsubscribe-consumer-subaccount/README.md index 27a1ec3..4fd10b6 100644 --- a/docu/2-basic/8-unsubscribe-consumer-subaccount/README.md +++ b/docu/2-basic/8-unsubscribe-consumer-subaccount/README.md @@ -1,5 +1,8 @@ # Unsubscribe from a Consumer Subaccount +- ### **Kyma** ✅ +- ### **Cloud Foundry** ✅ + > **Important** - If you are planning to setup the **Advanced Version** next, please consider this part of the tutorial optional! If a subaccount is subscribed to our multitenant SaaS sample application and created a service instance for the related SaaS API, the subaccount will resemble the below screenshot. @@ -31,7 +34,9 @@ The following steps show you how to unsubscribe from the SaaS application and ho ## 2. Check successful Unsubscription -Please check, whether the Sustainable SaaS API Service Broker has unregistered successfully. The **Sustainable SaaS API Service Broker** is automatically unregistered when unsubscribing from the Sustainable SaaS application in a Consumer Subaccount. Consequently, the Sustainable SaaS API Service should not be visible in a Consumer Subaccount anymore, when a new service instance creation attempt is made from that subaccount. As you can see below, the **Sustainable SaaS API** Service is not visible anymore. +Please check, whether the **Sustainable SaaS API Service Broker** has unregistered successfully. The **Sustainable SaaS API Service Broker** is automatically unregistered when unsubscribing from the Sustainable SaaS application in a Consumer Subaccount. + +Consequently, the **Sustainable SaaS API Service** should not be visible in the Consumer Subaccount anymore, when a new service instance creation attempt is made from that subaccount. As you can see below, the **Sustainable SaaS API** Service is not visible anymore, but only the actual SaaS application itself. [
](./images/check-broker-unregister.png?raw=true)
diff --git a/docu/2-basic/9-undeploy-saas-application/README.md b/docu/2-basic/9-undeploy-saas-application/README.md
index d874f8e..8343cc1 100644
--- a/docu/2-basic/9-undeploy-saas-application/README.md
+++ b/docu/2-basic/9-undeploy-saas-application/README.md
@@ -1,26 +1,32 @@
-# Optional - Undeploy the SaaS Application
+# Undeploy the SaaS Application
+
+- ### **Kyma** ✅
+- ### **Cloud Foundry** ✅
> **Important** - If you are planning to setup the **Advanced Version** next, please consider this part of the tutorial optional!
-If you want to undeploy the SaaS application and all related services and resources from your Kmya Cluster or Cloud Foundry environment, please follow the steps below.
+If you want to undeploy the SaaS application and all related services and resources from your **Kmya Cluster** or **Cloud Foundry** environment, please follow the steps below.
-- [Optional - Undeploy the SaaS Application](#optional---undeploy-the-saas-application)
+- [Undeploy the SaaS Application](#undeploy-the-saas-application)
- [1. Undeploy the SaaS application](#1-undeploy-the-saas-application)
- [2. Check successful Undeployment](#2-check-successful-undeployment)
- [3. Further Information](#3-further-information)
-> **Important** - For the undeployment of a SaaS solutions from your Kyma Cluster or Cloud Foundry Environment, it is **essential** that all **Service Bindings** and **Service Instances** are deleted first, followed by deleting all existing **SaaS subscriptions** in each Consumer Subaccount! Otherwise, existing credential clones (e.g., created by XSUAA during the subscription dependency callbacks) will not be properly removed and corresponding Services Instances cannot be deleted without further ado!
+
+**Important** - For the undeployment of a SaaS solutions from your Kyma Cluster or Cloud Foundry Environment, it is **essential** that all **Service Bindings** and **Service Instances** are deleted first, followed by deleting all existing **SaaS subscriptions** in each Consumer Subaccount! Otherwise, existing credential clones (e.g., created by XSUAA during the dependency callbacks) will not be properly removed and corresponding Services Instances cannot be deleted without further ado!
## 1. Undeploy the SaaS application
-1.1. Delete all API Service instances from the **Consumer Subaccounts** before undeploying.
+1.1. Delete all API Service instances from the **Consumer Subaccounts** before undeploying the actual SaaS application from your Cloud Foundry landscape or Kyma Cluster.
-1.2. Make sure you unsubscribed from the SaaS application in all **Consumer Subaccounts** before starting the undeployment.
+1.2. Next, please make sure you successfully unsubscribed from the SaaS application in all **Consumer Subaccounts** before starting the undeployment process.
> **Hint** - You can check and also remove existing subscriptions using the Subscription Management Dashboard ([click here](https://help.sap.com/docs/btp/sap-business-technology-platform/using-subscription-management-dashboard) for details).
-1.3. Ensure that your API Service Broker is properly unregistered ([click here](../9-unsubscribe-consumer-subaccount/README.md#2-check-successful-unsubscription)) from all **Consumer Subaccounts**.
+1.3. Ensure that your API Service Broker is properly unregistered ([click here](../8-unsubscribe-consumer-subaccount/README.md#2-check-successful-unsubscription)) from all **Consumer Subaccounts**. The API Service may no longer appear in the Service selection or Marketplace menu of any subscriber account.
+
+> **Important** - We keep in reiterating this, but properly unsubscribing from each Consumer Subaccount (unregistering all Service Broker registrations) will save you a lot of painful manual work.
**Kyma**
@@ -52,30 +58,33 @@ $ cf undeploy susaas --delete-services --delete-service-keys
**Cloud Foundry**
-Check within the SAP BTP Cockpit or using the Cloud Foundry CLI, whether all Applications, Services Instances and Service Bindings have been successfully removed from your Cloud Foundry environment in your Provider Subaccount. If any artifacts remain, please try to delete them manually. Please make sure to delete them manually in the following order:
+Check within the SAP BTP Cockpit or using the Cloud Foundry CLI, whether all Applications, Services Instances and Service Bindings have been successfully removed from your Cloud Foundry landscape in your Provider Subaccount. If any artifacts remain, please try to delete them manually. Please make sure to delete them manually in the following order:
- Application instances
- Service keys
- Service instances
-In case of failed deletions, please check the **General** section below!
+In case of failed deletions (e.g., XSUAA, Destination Service or SaaS-Registry), please check the **General** section below!
**Kyma**
-Check within your Kyma Cluster, whether all Service Bindings, Service Instances, Secrets and Deployments have been successfully remove. If there are any artifacts remaining in the Kyma Cluster of your Provider Subaccount, please delete them in the following order:
+Check within your Kyma Cluster, whether all Service Bindings, Service Instances, Secrets and Deployments have been successfully removed. You can do so using the Kyma Dashboard or the kubectl command line tool. If there are any artifacts remaining in the Kyma Cluster of your Provider Subaccount, please delete them in the following order:
-- Application workloads (Jobs, Deployments, ReplicaSets, Pods)
+- Application workloads (Deployments, ReplicaSets, Jobs, Pods)
- SAP BTP Service Bindings
- SAP BTP Service Instances
+- Remaining Objects (Secrets, ConfigMaps)
-Also double-check if all Istio-related objects as well as Network Policies and Config Maps have been successfully removed. In case of failed deletions, please check the **General** section below!
+Also double-check if all Istio-related objects as well as Network Policies and Config Maps have been successfully removed. In case of failed deletions (e.g., XSUAA, Destination Service or SaaS-Registry), please check the **General** section below!
**General**
-You might face a scenario, in which the deletion of the Authorization & Trust Management, the SaaS Provisioning or Destination Service fails. This happens if you did not properly unsubscribe all existing SaaS tenants or did not unregister all Service Broker registrations in the respective subaccounts.
+You might face a scenario, in which the deletion of the Authorization & Trust Management, the SaaS Provisioning or Destination Service fails. This is likely to happen, if you did not properly unsubscribe all existing SaaS tenants or did not unregister all Service Broker registrations in your Consumer Subaccounts.
+
+To unregister existing Service Broker registrations, please re-deploy the application and unregister the remaining Service Broker registrations using e.g., the SAP BTP CLI. If existing Consumer Subaccount subscriptions have not been properly removed, you can follow the same approach and remove the subscriptions after re-deployment.
-To unregister existing Service Broker registrations, please re-deploy the application and unregister the remaining Service Broker registrations using e.g., the SAP BTP CLI. If existing Consumer Subaccount subscriptions have not been properly removed, you can follow the same approach and remove the subscriptions after re-deployment. Alternatively, you can also use the Subscription Management Dashboard and delete the remaining subscriptions by skipping the dependency callback.
+Alternatively, you can also use the Subscription Management Dashboard and delete the remaining subscriptions by skipping the dependency callback.
## 3. Further Information
diff --git a/docu/3-advanced/0-introduction-advanced-version/README.md b/docu/3-advanced/0-introduction-advanced-version/README.md
index ec86afa..f7387ad 100644
--- a/docu/3-advanced/0-introduction-advanced-version/README.md
+++ b/docu/3-advanced/0-introduction-advanced-version/README.md
@@ -1,6 +1,9 @@
# Advanced Version Introduction
-The **Basic** and **Advanced Version** of the sample application require the same setup, which means you have to get started with the **Basic** Version, before challenging yourself with the Advanced Version. The **Expert Features** contain additional components and tutorials that can be applied to both the Basic **and** Advanced Version.
+- ### **Kyma** ✅
+- ### **Cloud Foundry** ✅
+
+The **Advanced Version** of the sample application requires a certain **Basic** setup, which means you have to get started with the **Basic Version**, before challenging yourself with the Advanced Version. The **Expert Features** contain additional components and tutorials that can be applied to both the Basic **and** Advanced Version.
In the [Basic Version](../../2-basic/0-introduction-basic-version/README.md) we provided you with the core elements required for a **Cloud Foundry** or **Kyma-based** Software as a Service (SaaS) application on SAP Business Technology Platform (SAP BTP). The idea of the **Advanced Version** is about taking all the features implemented in the **Basic Version** and extending them to the next level with other great services provided by SAP BTP. This will take you one step closer to an enterprise-read SaaS application
@@ -22,9 +25,9 @@ Take a look at the following architectures to get an idea of the Advanced Versio
## 1. Step-by-Step Guide
-For completing the **Advanced Version** of this tutorial please run through the steps described in the following Readme documents.
+For completing the **Advanced Version** of this tutorial please run through the steps described in the following Readme documents. If not stated differently, the respective step-by-step tutorial will cover both runtimes.
-1. **Understand repository changes** compared to the Basic Version. ➜ ([click here](../1-understand-repo-structure/README.md))
+1. **Prepare the Provider Subaccount** by adding additional entitlements. ➜ ([click here](../1-prepare-provider-subaccount/README.md))
2. Set up the **Central User Management** feature using **SAP Identity Authentication Service** (SAP IAS). ➜ ([click here](../2-central-user-management-ias/README.md))
3. Configure an SAP S/4HANA system for an **automated sample data push**. ➜ ([click here](../3-push-data-s4hana-system/README.md))
4. Integrate **SAP API Management** for API management and monitoring. ➜ ([Kyma](../4-kyma-integrate-api-management/README.md)) ([Cloud Foundry](../4-cf-integrate-api-management/README.md))
@@ -38,7 +41,7 @@ The **Advanced Version** provides the sample implementation of a CAP-based multi
- basic enterprise application features like
- **Alert Notification Service** informing you about issues with your application like a crash or errors during Tenant onboarding.
- - **Horizontal Autoscaling** which is scaling your SaaS application components in case of increased workload by your SaaS tenants.
+ - **Autoscaling** which is scaling your SaaS application components in case of increased workload by your SaaS tenants.
- **HTML5 Application Repository** storing and serving your static application content making your app more resilient.
- important components for SaaS usage like
- **SAP HANA Cloud** allowing you to use the powerful container concept for Tenant separation on the same database.
@@ -48,14 +51,14 @@ The **Advanced Version** provides the sample implementation of a CAP-based multi
- **application** plan which handles the XSUAA-based application authentication and authorization of all tenants.
- **broker** plan which takes care of the XSUAA-based API access security requirements for all tenants.
- additional enterprise readiness features like an
- - (*) **SAP Cloud Identity** services for handling in-app user management operations on SAP Identity Authentication Service.
+ - (*) **SAP Cloud Identity** services for handling a Central User Management and In-App user management operations on SAP Identity Authentication Service.
- (*) **SAP S/4HANA push** example which enables consumers to push business data from their On-Premises systems in a certain format.
- (*) **SAP API Management** setup which allows SaaS Providers to add enterprise API qualities to the API endpoints provided to subscribers.
## 3. Advanced Version Result
-As a result of this Advanced tutorial, you have a SaaS application running in a Cloud Foundry environment or Kyma Cluster of your own SAP BTP Subaccount which
+As a result of this Advanced tutorial, you have a SaaS application running in the **Cloud Foundry** environment or **Kyma Cluster** of your own SAP BTP Subaccount.
> (*) indicates that the feature is only available in the Advanced Version, all other features are also available in Basic Version.
diff --git a/docu/3-advanced/1-prepare-provider-subaccount/README.md b/docu/3-advanced/1-prepare-provider-subaccount/README.md
index ff8f78a..b56efd6 100644
--- a/docu/3-advanced/1-prepare-provider-subaccount/README.md
+++ b/docu/3-advanced/1-prepare-provider-subaccount/README.md
@@ -1,5 +1,8 @@
# Prepare the Provider Subaccount
+- ### **Kyma** ✅
+- ### **Cloud Foundry** ✅
+
In this chapter, you will learn how to prepare your SAP BTP Provider Subaccount for the deployment of the SaaS solution by assigning the additional entitlements required for the **Advanced Version**.
- [Prepare the Provider Subaccount](#prepare-the-provider-subaccount)
@@ -14,7 +17,7 @@ In this chapter, you will learn how to prepare your SAP BTP Provider Subaccount
As already mentioned, also the **Advanced Version** of this tutorial can be deployed to any SAP BTP environment using **Free (Tier) service plans** of your own **Pay-as-you-Go** (PAYG) or **CPEA** account. A tutorial how to setup a PAYG account (allowing you to use all Free Tier service plans) can be found in the [Tutorial Navigator](https://developers.sap.com/tutorials/btp-free-tier-account.html). A deployment to **Trial** Accounts is also possible, though it is not recommended due to limited resource availability (e.g., 14 days in case of Kyma).
-Please make sure you successfully set up the **Basic Version** of this tutorial before you get started with the **Advanced Version**. All entitlements listed in the Basic Version details ([click here](../../2-basic/2-prepare-provider-subaccount/README.md)) are also required for the Advanced Version.
+**Important** - Please make sure you successfully set up the **Basic Version** of this tutorial before you get started with the **Advanced Version**. All entitlements listed in the Basic Version details ([click here](../../2-basic/2-prepare-provider-subaccount/README.md)) are also required for the Advanced Version.
## 2. Entitlements for Advanced Version
@@ -46,7 +49,7 @@ Depending on which of the Advanced Version features you would like to set up, th
If you want to test the automated data push feature from an existing SAP solution, the sample setup requires a SAP solution that contains the Enterprise Procurement Model (EPM) model. The EPM is a demo application that integrates many SAP NetWeaver technologies that are used by SAP S/4HANA applications. It is based on a common business process model and follows the business object (BO) paradigm to support well-defined business logic.
-In this sample application you will learn how to [push data from the EPM module to the SaaS API](../7-push-data-s4hana-system/README.md) to migrate your business data to the multitenant business application for the sustainability calculations. You can use all **SAP S/4HANA** releases and also any other SAP systems which has an **SAP NetWeaver** stack version higher than 7.3. since these versions, all contain the EPM module by default.
+In this sample application you will learn how to [push EPM sample data to the SaaS API](../3-push-data-s4hana-system/README.md) to migrate your business data to the multitenant business application for the sustainability calculations. You can use all **SAP S/4HANA** releases and also any other SAP systems which has an **SAP NetWeaver** stack version higher than 7.3. since these versions, all contain the EPM module by default.
> **Important** - This steps described in this tutorial assume that you are using **at least the 2021** version of SAP S/4HANA. Some features (like the **OAuth Settings** in SM59) are only available since the SAP S/4HANA 2021 release. If your system is based on an older release, you need to invest some coding effort to implement the respective OAuth flows in ABAP yourself. Please check the community for blogs and tutorials on **Configuring OAuth 2.0 and Creating an ABAP Program That Uses OAuth 2.0 Client API**, which should give you a good idea how to set up a Client Credential flow in ABAP.
diff --git a/docu/3-advanced/2-central-user-management-ias/README.md b/docu/3-advanced/2-central-user-management-ias/README.md
index b0c9cfd..08a2412 100644
--- a/docu/3-advanced/2-central-user-management-ias/README.md
+++ b/docu/3-advanced/2-central-user-management-ias/README.md
@@ -1,5 +1,8 @@
# Central user management using SAP Identity Authentication Service
+- ### **Kyma** ✅
+- ### **Cloud Foundry** ✅
+
In this part of the tutorial, you will learn how you as a SaaS Provider can set up a central user management using SAP Identity Authentication Service (SAP IAS). This makes your solution independent from SAP ID Service, which requires users of your SaaS consumers to sign up for an SAP-managed user account. Using SAP IAS you can manage (register, unregister, reset passwords, ...) all SaaS Consumer users in a central place.
- [Central user management using SAP Identity Authentication Service](#central-user-management-using-sap-identity-authentication-service)
@@ -57,8 +60,8 @@ The usage of SAP IAS provides signification advantages for your SaaS application
In case you already have an existing trust between SAP XSUAA of Provider Subaccount and your SAP IAS tenant, there are only a few additional steps to take when setting up a new Consumer account.
-* Set up your central SAP IAS tenant as a trusted IdP in your Consumer Subaccounts. -* Disable the creation of shadow users in the SAP IAS trust configurations.
+* Set up your central SAP IAS tenant as a trusted IdP in your Consumer Subaccounts. +* Disable the creation of shadow users in the SAP IAS trust configurations. > **Important** - Make sure that the shadow user creation is **also disabled in your Provider Subaccount**! @@ -74,17 +77,17 @@ In case you don't have an SAP IAS tenant or you haven't configured it as a trust 2.3. If there is no SAP IAS tenant available for your customer account, you can create a new tenant from your Provider Subaccount or any other subaccount. Please switch to **Instances and Subscriptions** in the **Services** section and create a new service instance of type **Cloud Identity Service** with service plan **default**. -[
](./images/IAS_SetupIAS.png?raw=true)
+[](./images/IAS_SetupIAS.png?raw=true)
> **Important** - If you're missing this service or service plan, please make sure to add it to your subaccount entitlements. While the **default (Application)** service plan will create a new SAP IAS tenant, the **application** service plan will create a new application registration in an SAP IAS tenant configured as a trusted IdP to the respective subaccount.
-> [
](./images/IAS_EntConfig.png?raw=true)
+> [](./images/IAS_EntConfig.png?raw=true)
2.4. Decide if you want to set up a productive or test tenant of SAP Identity Authentication and click on **Create** to trigger the setup.
2.5. You or your SAP BTP Global Account administrator will receive a mail with instructions on how to initialize your new SAP IAS tenant once it is provisioned. The initial admin user can create further users or admins in SAP IAS.
-[
](./images/IAS_ActivationMail.png?raw=true)
+[](./images/IAS_ActivationMail.png?raw=true)
2.6. Once the IAS tenant is provisioned, it will also appear in the configuration popup of your **Trust Configuration** and you can finish the trust set up in your Consumer and Provider Subaccounts.
@@ -97,17 +100,18 @@ In case you don't have an SAP IAS tenant or you haven't configured it as a trust
Right after setting up the trust between your SAP IAS instance and your **Provider** and **consumer** subaccounts, please disable the **Automated Creation of Shadow Users** in the **Trust Configuration** of your SAP IAS trust settings. This is a one-time action, which you need to apply for each new Subscriber tenant!
-[
](./images/IAS_ShadowUser01.png?raw=true)
+[](./images/IAS_ShadowUser01.png?raw=true)
-[
](./images/IAS_ShadowUser02.png?raw=true)
+[](./images/IAS_ShadowUser02.png?raw=true)
An Automated creation of shadow users would result in a setup in which each and every SAP IAS user can authenticate to each Consumer Subaccount. As your central SAP IAS instance contains the users of all consumers, this is not desirable! Instead, we will create the subaccount-specific shadow users upon user creation in the SaaS in-app user management. While this is a bit more coding an maintenance effort, it provides a much more reliable and secure setup.
+
**Configure trusted domains in SAP IAS**
To allow an automated forwarding of users to the respective tenant SaaS instances after registration in SAP IAS, you need to add your SaaS application domain as a trusted domain in the SAP IAS **Tenant Settings**. Therefore, please login to SAP Identity Authentication Service as an Administrator and follow the screenshots below. SAP IAS will only allow redirects to domains which have been explicitly whitelisted in the Tenant Settings.
-[
](./images/IAS_TrustedDomain01.png?raw=true)
+[](./images/IAS_TrustedDomain01.png?raw=true)
**Kyma**
@@ -123,7 +127,7 @@ If required for increased security, don't use your Cloud Foundry or Kyma subdoma
## 4. Update your application deployment
-To enable the Central User Management leveraging SAP Identity Authentication Service in your environment, please make sure to update your application deployment accordingly. For this advanced feature, an additional Service Instance is required, generating a new application registration in your trusted SAP IAS tenant. Furthermore, this Service Instance will be bound to your backend application and allows you to programmatically interact with SAP IAS (e.g., to create new SaaS users).
+To enable the Central User Management leveraging SAP Identity Authentication Service in your environment, please make sure to update your application deployment accordingly. For this advanced feature, an additional Service Instance is required, generating a new application registration in your trusted SAP IAS tenant. Furthermore, this Service Instance will be bound to your backend application and allows you to programmatically interact with SAP IAS (e.g., to create new SaaS Consumer users).
### Kyma
@@ -133,9 +137,8 @@ By adding the **values-ias.yaml** file to your deployment or upgrade command, a
```sh
cd deploy/kyma
-helm upgrade susaas \
- ./charts/sustainable-saas -n 
](./images/APP_Mtaext_Dir.png?raw=true)
@@ -237,14 +241,14 @@ mbt build -e ./mtaext/free-advanced-private.mtaext
cf deploy
```
-Once the deployment is finished, you are good to go and the integration with SAP Identity Authentication should be working as expected. In your **Service Instances** you should now see a new instance of type **identity** and plan **application**, which has a **Service Binding** to your Backend Service.
+Once the deployment has finished, you are good to go and the integration with SAP Identity Authentication should be working as expected. In your **Service Instances** you should now see a new instance of type **identity** and plan **application**, which has a **Service Binding** to your Backend Service.
[
](./images/IAS_InstanceCf.png?raw=true)
**Details**
-Below, you can find the Service Instance definition (which is part of the Deployment Descriptor Extension file) of the SAP Cloud Identity Service Instance being created.
+Below, you can find the Service Instance definition (which is part of the Deployment Descriptor Extension) of the SAP Cloud Identity Service Instance being created.
```yaml
# SAP Cloud Identity Service Instance
@@ -282,7 +286,7 @@ Besides the new Service Instance, also a new Service Binding between the **SaaS
credential-type: X509_GENERATED
```
-Like Kyma scenario, also in case of Cloud Foundry, there are no changes required in the application logic, as the availability of the SAP Cloud Identity Service Binding is determined at runtime. Consequently, different logic is executed.
+Like in the Kyma scenario, also in case of Cloud Foundry, there are no changes required in the application logic, as the availability of the SAP Cloud Identity Service Binding is determined at runtime. Consequently, different logic is being executed.
**/code/srv/srv/utils/user-management.js**
@@ -425,7 +429,7 @@ Before testing the SAP IAS integration, please double check whether your meet th
- Domain of your SaaS application added as trusted domain in SAP IAS ([click here](#3-configure-the-xsuaa-and-ias-settings))
- Application deployment updated with new Service Instance and Service Binding ([click here](#4-update-your-application-deployment))
- Basic understanding of the registration and login flow ([click here](#5-understand-the-architecture-and-login-flow))
-- Existing Tenant Subaccount with Sustainable SaaS Subscription ([click here](../../2-basic/5-subscribe-consumer-subaccount/README.md))
+- Existing Tenant Subaccount with Sustainable SaaS Subscription ([click here](../../2-basic/4-subscribe-consumer-subaccount/README.md))
All set? Great - then let's check whether the SAP IAS Integration works as expected!
diff --git a/docu/3-advanced/3-push-data-s4hana-system/README.md b/docu/3-advanced/3-push-data-s4hana-system/README.md
index c247faa..01d0265 100644
--- a/docu/3-advanced/3-push-data-s4hana-system/README.md
+++ b/docu/3-advanced/3-push-data-s4hana-system/README.md
@@ -1,5 +1,8 @@
# Push data from SAP S/4HANA system
+- ### **Kyma** ✅
+- ### **Cloud Foundry** ✅
+
A feature that will make your SaaS application even more valuable to your SaaS consumers, is an integration with other SAP solutions. This will allow your consumers to make use of their own data within your SaaS service offering and gain real business value out of it. For sure a SaaS solution can always offer an Excel upload or an online interface for maintaining tenant-specific data, but an automated backend integration is more than just a nice to have especially when dealing with constantly changing data sets.
In this part of the tutorial, you will learn how your SaaS consumers can connect an ABAP-based backend like SAP S/4HANA with their Consumer Tenant SaaS instance and push data into their Tenant database container in an automated fashion.
@@ -21,7 +24,7 @@ In this part of the tutorial, you will learn how your SaaS consumers can connect
- [11. Further Information](#11-further-information)
-> **Important** - The CAP payload size limitation for this sample has been increased to 50 MB. Please check the *server.js* file ([click here](../../../code/api/server.js)) to remove or modify this setting if required. Keep in mind that when using SAP API Management, different file size limits apply and you will need to using streaming features to upload larger files.
+> **Important** - The CAP payload size limitation for this sample has been increased to 50 MB. Please check the *server.js* file ([click here](../../../code/api/srv/server.js)) to remove or modify this setting if required. Keep in mind that when using SAP API Management, different file size limits apply and you will need to using streaming features to upload larger files.
## 1. Architecture
diff --git a/docu/3-advanced/4-cf-integrate-api-management/README.md b/docu/3-advanced/4-cf-integrate-api-management/README.md
index ba352f9..da5e4f5 100644
--- a/docu/3-advanced/4-cf-integrate-api-management/README.md
+++ b/docu/3-advanced/4-cf-integrate-api-management/README.md
@@ -1,5 +1,10 @@
# Integrate SAP API Management
+- ### **Kyma** ❌
+- ### **Cloud Foundry** ✅
+
+**Important** - This part of the tutorial is required for **Cloud Foundry** deployments only!
+
As your SaaS application contains an API that allows the SaaS consumers to interact programmatically with their tenant database containers, you need to ensure that your API endpoints are properly managed and monitored. For this purpose, you should implement features like rate limiting to prevent e.g., DoS attacks. Furthermore, you can ensure fair usage of the resources among your consumers by e.g., setting up a quota depending on the chosen plan. A premium consumer might be eligible to send more requests per second than a standard consumer. Proper monitoring of your API will help you to analyze performance issues and to identify problems of your consumers.
In this part of the mission, you will learn how to ensure that each and every request to your SaaS API is first going through SAP API Management, which will be the dedicated standard solution provided by SAP for all API-related requirements.
@@ -21,7 +26,7 @@ In this part of the mission, you will learn how to ensure that each and every re
## 1. Architecture
-SAP API Management is a new component in the central part of the **Advanced Scope** architecture. While in the Basic Scope, the API calls were directly accessing the CAP-based API service, now all requests will be passing through this additional component, giving you great flexibility in how to handle your in and outbound API traffic.
+SAP API Management is a new component in the central part of the **Advanced Version** architecture. While in the Basic Version, the API calls were directly accessing the CAP-based API service, now all requests will be passing through this additional component, giving you great flexibility in how to handle your in and outbound API traffic.
See the relevant part of the solution architecture below (click to enlarge):
@@ -60,16 +65,15 @@ cf brs `+>cf brs cfapps.eu10.hana.ondemand.com susaas-apim-route-service --hostname dev-susaas-api-srv -c '{\"api_name\":\"SusaaS-API-Proxy\"}' + * **route service** - The name of your route-service instance created in the [last step](./README.md#3-apim-as-route-service). * **API-Proxy name** - You're free to choose the name of your API-Proxy in API Management. * **API service domain** - The domain of your API service like *cfapps.eu10.hana.ondemand.com*. * **API service hostname** - The hostname of your API service returned by the *cf apps* CLI command.
[
](./images/API_Hostname.png?raw=true)
-
->**Sample**->cf brs cfapps.eu10.hana.ondemand.com susaas-apim-route-service --hostname dev-susaas-api-srv -c '{\"api_name\":\"SusaaS-API-Proxy\"}' - > **Important** - The command might differ depending on your cf CLI version. You can use *cf brs --help* to find the correct command related to your cf CLI version. Also make sure to change the change the API service domain in case of Custom Domain usage. After successfully running this command in your cf CLI, you will see a new API Proxy called **SusaaS-API-Proxy** in your SAP API Management **Develop** menu. diff --git a/docu/3-advanced/4-kyma-integrate-api-management/README.md b/docu/3-advanced/4-kyma-integrate-api-management/README.md index e3e911f..123d2c2 100644 --- a/docu/3-advanced/4-kyma-integrate-api-management/README.md +++ b/docu/3-advanced/4-kyma-integrate-api-management/README.md @@ -1,5 +1,10 @@ # Integrate SAP API Management +- ### **Kyma** ✅ +- ### **Cloud Foundry** ❌ + +**Important** - This part of the tutorial is required for **Kyma** deployments only! + As your SaaS application contains an API that allows your Subscriber to interact programmatically with their Tenant database containers, you need to ensure that your API endpoints are properly managed and monitored. For this purpose, you should implement features like **Rate Limiting** to prevent DoS attacks. Furthermore, you can ensure fair usage of the resources among your consumers by setting up a **Quota** based on the chosen service plan. A premium Subscriber can be eligible to send more requests per second than a standard Consumer. Proper monitoring of your API will help you analyze performance issues and to identify problems of your consumers. In this part of the tutorial, you will learn how to ensure that each and every request targeting your SaaS API is passing through SAP API Management first. SAP API Management (as part of SAP Integration Suite), is SAP's standard cloud software offering for all API-related requirements. @@ -31,18 +36,21 @@ SAP API Management is a new component in the central part of the **Advanced Vers ## 2. Prerequisites -For this setup, please make sure you have an SAP API Management tenant up and running. As SAP API Management is a capability of **SAP Integration Suite**, please subscribe to SAP Integration Suite and activate the respective **API Management** feature. Check the following SAP Help documentation to find a detailed step-by-step guide ([click here](https://help.sap.com/docs/SAP_CLOUD_PLATFORM_API_MANAGEMENT/66d066d903c2473f81ec33acfe2ccdb4/f6eb4332cd5144ef91f4a84cc614ba1c.html?locale=en-US)). As part of this documentation, we cannot provide additional details on the setup process of SAP Integration Suite. +For this setup, please make sure you have an SAP API Management tenant up and running. As SAP API Management is a capability of **SAP Integration Suite**, please subscribe to SAP Integration Suite and activate the respective **API Management** feature. Check the following SAP Help documentation to find a detailed step-by-step guide ([click here](https://help.sap.com/docs/sap-api-management/sap-api-management/setting-up-api-management-capability-from-integration-suite?locale=en-US)). As part of this documentation, we cannot provide additional details on the setup process of SAP Integration Suite. [
](./images/API_IntegrationSuite.png?raw=true)
## 3. Integration Setup
-While Cloud Foundry offers a very convenient integration option using so-called **Route Services** (directly intercepting the traffic targeting your API), in Kyma we need to setup the necessary routing ourself. As already covered in the introductory Kyma chapters ([see here](../../2-basic/8-kyma-resources-helm/README.md)), any request targeting our Kyma API Service is initially routed to **SAP API Management**, where relevant API Rules (Rate Limiting, Quotas) are being checked.
+While Cloud Foundry offers a very convenient integration option using so-called **Route Services** (directly intercepting the traffic targeting your API), in Kyma we need to setup the necessary routing ourself. As already covered in the introductory Kyma chapters ([see here](../../2-basic/7-kyma-resources-helm/README.md)), any request targeting our Kyma API Service is initially routed to **SAP API Management**, where relevant API Rules (Rate Limiting, Quotas) are being checked.
+
+Only if those rules are passed, the traffic is send back to Kyma and routed to the actual API Service workloads. The relevant SAP API Management instance details for this routing have to be maintained in an additional *values-apim.yaml* file.
-Only if those rules are passed, the traffic is send back to Kyma and routed to the actual API Service workloads. The relevant SAP API Management instance details for this routing have to be maintained in the *values.yaml* file of the Umbrella Helm Chart.
+3.1. Below you can see a sample-configuration, containing all details required for the integration on the Kyma side. You can maintain your own environment specific credentials in the *deploy/kyma/charts/sustainable-saas/values-apim.yaml* file ([click here](../../../deploy/kyma/charts/sustainable-saas/values-apim.yaml)).
-3.1. Below you can see a sample-configuration, containing all details required for the integration on the Kyma side. You can maintain your own environment specific credentials in the *deploy/kyma/charts/sustainable-saas/values-apim.yaml* file. Just make sure to create a copy of the file first and add **-private** to the filename, so that your environment specific details are not being pushed to GitHub.
+> **Important** - Just make sure to create a copy of the file first and add **-private** to the filename, so that your environment specific details are not being pushed to GitHub. Your repository should look like the following.
+> [
](./images/API_RepoStruct.png?raw=true)
```yaml
api:
@@ -68,7 +76,7 @@ api:
sub: sb-
](./images/API_KeyValue01.png?raw=true)
3.5. Create a new Key Value Map named **susaas-api** containing the **Client Id** and **Token Endpoint** of your XSUAA Service Instance.
-> **Hint** - You can find the required details in your **\+> > ```kubectl get secret
+> > ```kubectl get secret
+> > ```kubectl get secret
> [
](./images/API_SecretDetails.png?raw=true)
- clientId: **clientid** property of Kyma Secret
@@ -112,14 +124,14 @@ helm upgrade susaas -n susaas \
- tokenEndpoint: **url** property of Kyma Secret (**without https://**)
> Example -> sap-demo.authentication.us20.hana.ondemand.com
-[
](./images/API_KeyValue02.png?raw=true)
+ [](./images/API_KeyValue02.png?raw=true)
3.6. Create a second **Key Value Map** named **susaas-api-key** containing the **Client Secret** of your XSUAA Service Instance. Enable encryption for this Key Value Map before you save it.
- clientSecret : **clientsecret** property of the aforementioned Kyma Secret.
> Example -> ac4f13bc-a1b2-c3d4-e5f6-38e067544oayNBjvt=
-[
](./images/API_KeyValue03.png?raw=true)
+ [](./images/API_KeyValue03.png?raw=true)
3.7. As the provided sample **API Proxy** contains an additional monitoring features (like tracking the XSUAA Zone ID of the client as well as the requested OData entity), please add those additional **Dimensions** in the **Monitoring** section of your SAP API Management instance. Therefore, please switch to the **APIs** section of the **Monitoring** menu and click on **+ Add**.
@@ -135,25 +147,25 @@ helm upgrade susaas -n susaas \
3.9. Return to the **Design** environment and upload the provided sample **APIProxy.zip** file, which you can find in the **files** subfolder ([click here](./files/)) of this tutorial.
-[
](./images/API_Upload01.png?raw=true)
-[
](./images/API_Upload02.png?raw=true)
+[](./images/API_Upload01.png?raw=true)
+[](./images/API_Upload02.png?raw=true)
3.10. Once uploaded, please open the susaas-api **API Proxy** definition and update the **Target Endpoint** with your Kyma API Service URI (e.g., susaas-api-default.a1b2c3d4.kyma.ondemand.com) as you can see in the following screenshots.
> **Hint** - If you are using a **custom domain** in your Kyma environment, please also use in this context (e.g., susaas-api-default.sap-demo.com).
-[
](./images/API_Proxy01.png?raw=true)
-[
](./images/API_Proxy03.png?raw=true)
+[](./images/API_Proxy01.png?raw=true)
+[](./images/API_Proxy03.png?raw=true)
-[
](./images/API_Proxy04.png?raw=true)
-[
](./images/API_Proxy05.png?raw=true)
+[](./images/API_Proxy04.png?raw=true)
+[](./images/API_Proxy05.png?raw=true)
3.11. Save your changes and deploy the **API Proxy** as shown in the following screenshots.
-[
](./images/API_Proxy06.png?raw=true)
-[
](./images/API_Proxy07.png?raw=true)
+[](./images/API_Proxy06.png?raw=true)
+[](./images/API_Proxy07.png?raw=true)
-[
](./images/API_Proxy08.png?raw=true)
+[](./images/API_Proxy08.png?raw=true)
This is it - From now on, all requests targeting your Kyma API Service workloads will be routed through SAP API Management to enforce policies like **Rate Limiting** or **Quotas**. If the policies checks are passed, the request is returning to Kyma and is served by our API Service **Target Endpoint**. In the next chapter, we will provide you with a sneak peak of what is happening under the hood of this architecture.
@@ -296,7 +308,7 @@ While you are an expert for the theoretical concept now, let's face the school o
## 5. API Policy Deep Dive
-The API Policies of our sample API Proxy are primarily based on SAP API Management Standard features. In the following section of the tutorial, you will learn how to set up some of the used API Policies yourself. This includes a Spike Arrest component for rate limiting and different Quotas based on the plan (standard/premium) selected by a Subscriber.
+The API Policies of our sample API Proxy are primarily based on SAP API Management Standard features. In the following section of the tutorial, you will learn how to set up some of the used API Policies yourself. This includes a Spike Arrest component for rate limiting and different Quotas based on the plan (trial/standard/premium) selected by a Subscriber.
> **Important** - The following steps have already been completed in the sample API Proxy which you deployed in the beginning of this tutorial (**APIProxy.zip**). If you want to redo the following part of the step-by-step guide, feel free to remove the existing API Proxy and upload the **APIProxyPolicies.zip**. Otherwise, just follow along and try to reflect the steps and components in your existing API Proxy.
@@ -346,7 +358,7 @@ The Spike Arrest Policy allows you to throttle the number of requests processed
](./images/API_SpikeArrest02.png?raw=true)
+[](./images/API_SpikeArrest02.png?raw=true)
### 5.3. API Quota Policies
diff --git a/docu/3-advanced/4-kyma-integrate-api-management/images/API_Architecture.png b/docu/3-advanced/4-kyma-integrate-api-management/images/API_Architecture.png
index 56744e4..8818028 100644
Binary files a/docu/3-advanced/4-kyma-integrate-api-management/images/API_Architecture.png and b/docu/3-advanced/4-kyma-integrate-api-management/images/API_Architecture.png differ
diff --git a/docu/3-advanced/4-kyma-integrate-api-management/images/API_RepoStruct.png b/docu/3-advanced/4-kyma-integrate-api-management/images/API_RepoStruct.png
new file mode 100644
index 0000000..010e316
Binary files /dev/null and b/docu/3-advanced/4-kyma-integrate-api-management/images/API_RepoStruct.png differ
diff --git a/docu/4-expert/-CloudFoundry-/configure-transport-management/README.md b/docu/4-expert/-CloudFoundry-/configure-transport-management/README.md
index f1e1c0e..2a1d7d4 100644
--- a/docu/4-expert/-CloudFoundry-/configure-transport-management/README.md
+++ b/docu/4-expert/-CloudFoundry-/configure-transport-management/README.md
@@ -1,21 +1,29 @@
# Setup SAP Cloud Transport Management
-In this part of the **Expert scope** you will learn how to set up the **SAP Cloud Transport Management** service for continuous deployment of your SaaS solution to further SAP BTP subaccounts like a Test oder Production environment.
+- ### **Kyma** ❌
+- ### **Cloud Foundry** ✅
-1. [Introduction](#1-Introduction)
-2. [Setup SAP Cloud Transport Management](#2-Setup-SAP-Cloud-Transport-Management)
-3. [Assign User Roles and Permissions](#3-Assign-User-Roles-and-Permissions)
-4. [Configuring the TMS Landscape](#4-Configuring-the-TMS-Landscape)
-5. [Connect to CI/CD Pipeline](#5-Connect-to-CI/CD-Pipeline)
-6. [Import queue of Cloud Transport Management](#6-Import-queue-of-Cloud-Transport-Management)
-7. [Further Information](#7-Further-Information)
+> **Hint** - This Expert Feature requires refactoring and some screenshots and steps might be outdated.
+
+In this part of the **Expert Features** you will learn how to set up the **SAP Cloud Transport Management** service for continuous deployment of your SaaS solution to further SAP BTP subaccounts like a Test oder Production environment.
+
+- [Setup SAP Cloud Transport Management](#setup-sap-cloud-transport-management)
+ - [1. Introduction](#1-introduction)
+ - [2. Setup SAP Cloud Transport Management](#2-setup-sap-cloud-transport-management)
+ - [3. Assign User Roles and Permissions](#3-assign-user-roles-and-permissions)
+ - [4. Configuring the TMS Landscape](#4-configuring-the-tms-landscape)
+ - [Create Transport Destinations](#create-transport-destinations)
+ - [Use the Transport Landscape Wizard](#use-the-transport-landscape-wizard)
+ - [5. Connect to CI/CD Pipeline](#5-connect-to-cicd-pipeline)
+ - [6. Import queue of Cloud Transport Management](#6-import-queue-of-cloud-transport-management)
+ - [7. Further information](#7-further-information)
## 1. Introduction
As soon as you have a release candidate of your app version in form of a fully qualified archive, you want to propagate it to your test or production subaccount. You can do it either fully automated as part of a pipeline – ideally based on the Continuous Integration best practices or pipeline templates or with a standardized, enterprise-ready change management process, if you desire more control especially of your production environment – using our cloud-based **SAP Cloud Transport Management** service.
-In the following part of the **Expert Scope** we will show how to combine SAP CI/CD service & SAP Cloud Transport Management service combining the best of both worlds.
+In the following part of the **Expert Features** we will show how to combine SAP CI/CD service & SAP Cloud Transport Management service combining the best of both worlds.
We can differentiate -
diff --git a/docu/4-expert/-CloudFoundry-/custom-domain-usage/README.md b/docu/4-expert/-CloudFoundry-/custom-domain-usage/README.md
index 33f6785..43c94c3 100644
--- a/docu/4-expert/-CloudFoundry-/custom-domain-usage/README.md
+++ b/docu/4-expert/-CloudFoundry-/custom-domain-usage/README.md
@@ -1,31 +1,43 @@
# Custom Domain Usage
-In this part of the mission you will learn how to configure a custom domain for your SaaS application consumers. The topic of custom domain usage is very comprehensive and we can only cover certain sample scenarios. Depending on your requirements as a SaaS provider and the demand of your customers, things can get complicated quickly!
-<<<<<<< Updated upstream
+- ### **Kyma** ❌
+- ### **Cloud Foundry** ✅
-1. [Introduction](#1-Introduction)
-2. [SSL certificates](#2-SSL-certificates)
-3. [Domain considerations](#3-Domain-considerations)
-4. [Custom Domain Service](#4-Custom-Domain-Service)
-5. [CNAME record in DNS](#5-CNAME-record-in-DNS)
-6. [Custom Domain Route Mapping](#6-Custom-Domain-Route-Mapping)
-7. [Multi region intelligent routing](#7-Multi-region-intelligent-routing)
-8. [Further Information](#8-Further-Information)
+In this part of the mission you will learn how to configure a custom domain for your SaaS application consumers. The topic of custom domain usage is very comprehensive and we can only cover certain sample scenarios. Depending on your requirements as a SaaS provider and the demand of your customers, things can get complicated quickly!
-So, in this part of the **Expert Scope**, you will learn how to get from the default cfapps domain (e.g., **abc-7k7tmze3-susaas.cfapps.eu10...**), to a SaaS domain based on your custom domain (e.g., **abc-7k7tmze3.susaas.sap-demo.com**) to a proper consumer-specific custom domain (e.g., **abc.susaas.sap-demo.com**) using the Custom Domain Service. If you want to set up the sample scenario with your own custom domain, please make sure to to use the correct MTA extension descriptor file ([click here](https://github.com/SAP-samples/btp-cf-cap-multitenant-susaas/blob/advanced/configs/deployment/free-tier-domain.mtaext)). Search for the placeholder \
](./images/CDS_Mtaext.png?raw=true)
-Then go ahead with the build and deployment as explained in the **Basic** and **Advanced** scope.
+Place the file in your */deploy/cf/mtaext* directory adding the **-private** filename suffix. Then go ahead with the build and deployment as explained in the **Basic** and **Advanced** Features.
```
-$ cf deploy mta_archives/susaas_0.0.1.mtar -e ./configs/deployment/free-tier-domain.mtaext
+mbt build -e ./mtaext/free-basic-domain-private.mtaext
+cf deploy mta_archives/susaas_0.0.1.mtar
```
## 1. Introduction
-The SaaS application in our **Basic** and **Advanced Scope**, uses the default cfapps domains offered by SAP in the different regions like **cfapps.eu10.hana.ondemand.com**. The resulting consumer subdomains look similar to the following in the sample scenario:
+The SaaS application in our **Basic** and **Advanced Features**, uses the default cfapps domains offered by SAP in the different regions like **cfapps.eu10.hana.ondemand.com**. The resulting consumer subdomains look similar to the following in the sample scenario:
* **abc-8db8a40e**-susaas-test.cfapps.eu10.hana.ondemand.com
* **abc-7k7tmze3**-susaas.cfapps.eu10.hana.ondemand.com
@@ -42,7 +54,7 @@ As the consumer-specific hostname is build based on the consumer's subaccount su
[
](./images/SubDom_dyn.png?raw=true)
-Okay, so how can the above setup be improved to achieve an enterprise-ready setup with a fully flexible consumer subdomain based on a custom domain owned by the provider like **susaas.com** or **susaas.sap-demo.com**? Well, This is exactly what you will learn in this part of the **Expert Scope**.
+Okay, so how can the above setup be improved to achieve an enterprise-ready setup with a fully flexible consumer subdomain based on a custom domain owned by the provider like **susaas.com** or **susaas.sap-demo.com**? Well, This is exactly what you will learn in this part of the **Expert Features**.
> **Important** - The [**SAP Custom Domain Service**](https://discovery-center.cloud.sap/serviceCatalog/custom-domain?service_plan=custom-domain) can only be added as **paid plan** in **PAYG** or **CPEA** accounts. Please check the respective pricing details ([click here](https://discovery-center.cloud.sap/serviceCatalog/custom-domain?service_plan=custom-domain®ion=all&commercialModel=cloud&tab=service_plan)) before adding and using this service in your SAP BTP account.
@@ -686,346 +698,3 @@ Please use the following links to find further information on the topics above:
* [Let's Encrypt](https://letsencrypt.org/)
* [GitHub - Route Multi-Region Traffic to SAP BTP Services Intelligently](https://github.com/SAP-samples/btp-services-intelligent-routing)
* [Microsoft - Traffic Manager documentation](https://learn.microsoft.com/en-us/azure/traffic-manager/)
-=======
-
-
-
-
-## 1. Introduction
-
-The SaaS application in our **Basic** and **Advanced Scope**, uses the default domains offered by SAP in the different regions like **cfapps.eu10.hana.ondemand.com**. The resulting consumer subdomains look similar to the following in the sample scenario:
-
-* **abc-7k7tmze3**-susaas[-dev/test].cfapps.eu10.hana.ondemand.com
-* **xyz-9v5lartu**-susaas[-dev/test].cfapps.eu10.hana.ondemand.com
-
-As the consumer-specific hostname is build based on the consumer's subaccount subdomain (e.g., abc-7k7tmze3), the resulting full qualified domain name doesn't look very nice as this subdomain by default contains a random ID. This ID is generated when keeping the recommended default values while setting up a new consumer subaccount.
-
-> **Important** - We **do not** recommend to change the subaccount subdomain upon setup to e.g., **abc** by removing the auto-generated ID. This will block the **abc** subdomain in the whole region! While this might work in some scenario, you will e.g., face issues when trying to create a subaccount subdomain for popular company names as these subdomains might already be taken!
-
-**Don't do this!**
-
-[
](./images/SubDom_fix.png)
-
-**Please do this instead!**
-
-[](./images/SubDom_dyn.png)
-
-
-Okay, so how can the above setup be improved to achieve an enterprise-ready setup with a fully flexible consumer subdomain based on a custom domain owned by the provider like **abc[-dev/test].susaas.com** or **xyz[-dev/test].susaas.com**.
-
-Well, This is exactly what you will learn in this part of the **Expert Scope**.
-
-> **Important** - The [**SAP Custom Domain Service**](https://discovery-center.cloud.sap/serviceCatalog/custom-domain?service_plan=custom-domain) can only be added as **paid plan** in **PAYG** or **CPEA** accounts. Please check the respective pricing details ([click here](https://discovery-center.cloud.sap/serviceCatalog/custom-domain?service_plan=custom-domain®ion=all&commercialModel=cloud&tab=service_plan)) before adding and using this service in your SAP BTP account.
-
-
-## 2. SSL certificates
-
-While the service name resonates differently, the Custom Domain service is charging you based on the number of activated SSL certificates. A single SSL certificate can be used to secure traffic of multiple domains or subdomains. Therefore, please make yourself familiar with some background knowledge on SSL certificates using your favorite search engine before setting up your Custom Domain service instance. It might save you a bunch of money!
-
-In case of a SaaS solution on SAP BTP, you as a SaaS provider should try to run your application with a minimal number of SSL certificates that cover your custom domain requirements. Especially the usage of multi-domain certificates or SAN certificates, can be useful in many scenarios.
-
-Below you can see some samples of SSL certificate types issued for one or multiple (wildcard) domains.
-
-
-**Single-Domain SSL Certificate**
-
-Enabling a secure connection for a dedicated single domain or subdomain.
-
->susaas.com
-
-
-**Wildcard SSL Certificate**
-
-Enabling a secure connection for a random number of subdomains of a dedicated domain. Does not secure the domain itself.
-
-> *.susaas.com- -> **Hint** - Supports same level subdomains only. For securing a sub-level subdomain, a new certificate is required. For example **.eu.susaas.com* would require a new wildcard certificate. - - -**Multi-Domain SSL Certificate** - -Enabling a secure connection for several dedicated domains. Also known as SAN certificate. Cannot include wildcard subdomains. - ->susaas.com
-eu.susaas.com
-us.susaas.com - - -**Multi-Domain Wildcard SSL Certificate** - -Enabling a secure connection for a random number of subdomains. Also known as SAN wildcard certificate. - ->*.susaas.com
-*.eu.susaas.com
-*.us.susaas.com - -> **Hint** - Keep in mind - a wildcard certificate only secures all subdomains on the same level but not on sub-levels. For example **.dev.eu.susaas.com would* require a new certificate. - - -**Further Multi-Domain SSL Certificate options** - -Also combinations of multiple subdomains and dedicated domains are possible in multi-domain certificates.
- -> susaas.com
-*.susaas.com
-*.eu.susaas.com
-*.dev.eu.susaas.com - - -Depending on your requirements, costs for an SSL certificate can quickly increase, whereas a single-domain SSL certificate is the cheapest option, while a multi-domain SSL certificate is the most expensive but powerful solution. Make sure you understand your setup when it comes to Custom Domain requirements in development, test and production landscapes. Also when providing your solution in different regions, you might need further subdomains and certificates. - -So in the end it's up to you to calculate and decide for your own approach based on the costs and expected effort. - -## 3. Things to consider - -When using a custom domain, for your SaaS scenario, there's a few things to consider. Please make sure to choose the correct setup for your requirements, as later changes might lead to unexpected URL changes for your existing consumers. - -Also keep in mind, the following list of considerations is not independent. You will probably end up in a mix of these points based on your landscape. - -> **Hint** - While for most of the scenarios, a dash-based separation might look like a more cost efficient solution, make sure you're clear on the negative side-effects. Especially with many consumers, the DNS maintenance will be a huge effort compared to the usage of dot-based separation and an additional certifiacte. - -Okay lets check some of the things you should consider before setting up your custom domain. - -### Number of SaaS applications - -[
](./images/CD_Apps.png)
-
-The number of certificates required, heavily depends on the number of SaaS applications you want to use in your landscape. Let's assume the following scenario where you only have one SaaS app in your subaccount:
-
-* *.app.com
-
-This leaves you with the requirement for one single SSL certificate. Okay, but how does this look in case of three different SaaS applications?
-
-* *.123.app.com or *.123-app.com
-* *.456.app.com or *.456-app.com
-* *.789.app.com or *.789-app.com
-
-Now you suddenly need three wildcard certificates or a SAN certificate including all of these domains. So you need to keep in mind how many apps you might deploy in your provider subaccount in the future and decide how to differentiate between them on a domain-basis.
-
-> **Hint** - Things can be cheaper using a dash as app separator, but it will in increase the effort on your side. In this case, one certificate for ***.app.com** is sufficient, but the maintenance effort on the DNS side will increase! ->* *-123.app.com ->* *-456.app.com ->* *-789.app.com
-> -> Wildcard CNAMEs like **\*.123.app.com** pointing to the **123 app** cannot be used anymore! Every customer needs it's own CNAME record for every app. Find more details below. - -
- -### Dev/Test/.../Production stages - -Depending on your setup, you will need at least two stages in a development landscape which are Development and Production. It is not advisable to directly deploy and modify an application in a productive environment. - -Well, what does that mean from a certificate perspective? Let's take a scenario with three stages. For sure, you can use different domains or subdomains for these stages: - -* *.dev.susaas.com or *.dev-susaas.com (Dev) -* *.test.susaas.com or *.test-susaas.com (Test) -* *.susaas.com (Prod) - -That means, three wildcard certificates are required or one SAN certificate containing all three wildcard domains. An alternative, would be the following approach: - -* *-susaas-dev.cfapps.eu10.hana.ondemand.com (Dev) -* *-susaas-test.cfapps.eu10.hana.ondemand.com (Test) -* *.susaas.com (Prod) - -As you can see, for the Dev and Test stage, we just simply kept the default **\*.cfapps** domain, which any SAP BTP user can use for free. The only job we have to do, is making sure that we have a clear application and landscape identifiert in our hostname. Only for the production environment, we're using a nice and shiny domain, so we end up with requiring only one single certificate for **\*.susaas.com**. - -[
](./images/CD_Stages.png)
-
-*Sample Setup for two stages*
-
-For sure, if your customer wants to have a test account, the URL won't be super intuitive compared to a productive tenant. If you want to achieve this, and you consumers cannot live with the default domain, you could think about the following:
-
-* *-susaas-dev.cfapps.eu10.hana.ondemand.com (Dev)
-* *.test.susaas.com (Test) or *.test-susaas.com (Test)
-* *.susaas.com (Prod)
-
-This would at least save you a wildcard certificate for the development landscape and you end up with two wildcard domains only. By the way, the following setups are not possible or recommended!
-
-* >**\*.susaas-dev**.cfapps.eu10.hana.ondemand.com- Not possible, as no further wildcard subdomains can be created for the default **cfapps** domain. Only SAP can create additional subdomains here. -* > **\*-dev**.cfapps.eu10.hana.ondemand.com
- Not recommended, as you might want to create routes for multiple apps in your provider subaccount in the future. Always include an application separator when using the default domain. -* > **\*-susaas**.cfapps.eu10.hana.ondemand.com
- Not recommended, as routes in a certain region are unique! You will not be able to create routes for other stages in a similar fashion! Always include the stage separator when using the default domain! Only exception - When the production landscape is also using the default domain, you can skip the stage separator here. - -So make up your thoughts how many stages you're gonna use in your landscape and which of these landscapes shall receive it's own custom domain. Don't forget, each wildcard certificate will cost you extra money. - -> **Hint** - Again, things can be cheaper using a dash as stage separator, but it will again increase the effort on your side. In this case, one certificate for ***.susaas.com** is sufficient, but the maintenance effort on the DNS side will increase!
->* *-dev.susaas.com ->* *-test.susaas.com ->* *.susaas.com -> -> Wildcard CNAMEs like **\*.dev.susaas.com** pointing to the Dev stage on the cannot be used anymore! Every customer needs it's own CNAME record for every stage. Find more details below. - -
- -### Multi region deployment - -If you decide to run your application in multiple regions around the globe, you should make sure to understand the influence in the Custom Domain requirements. While a custom Domain can be shared in Subaccounts of a Global Account within a certain region (e.g., eu10), this is not possbile across regions (e.g., from eu10 to us20). Let's assume the following scenario: - -* *.eu10.susaas.com -* *.us10.susaas.com -* *.ap20.susaas.com - -In case you want to separate your regional domains by a dot, that means you will need three different wildcard certificates for that scenario. Additionally, SAP will charge you a Custom Domain fee in each region you're using. - -> **Hint** - Once again, things can be cheaper using a dash as stage separator, but it will again increase the effort on your side. In this case, one certificate for **\*.susaas.com** is sufficient, but the maintenance effort on the DNS side will increase!
->* *-eu10.susaas.com ->* *-us10.susaas.com ->* *-ap20.susaas.com -> -> Wildcard CNAMEs like **\*.eu10.susaas.com** pointing to the **eu10 landscape** cannot be used anymore! Every customer needs it's own CNAME record for every landscape. Find more details below. - -
- -### Dash or dot based (region/stage) separation - -The format of your target domains heavily influences your number of required SSL certificates. To save on the cost of certificates, it can also be useful to use dashes to separate regions or landscapes instead of using separate subdomain levels. Check the following samples to see how to reduce the number of wildcard certificates required by using dashes instead of subdomains and a single wildcard certificate. - -| 3 wildcard certificates | 1 wildcard certificate | -|---|---| -| \
\
\
\
\
*.test.susaas.com
*.dev.susaas.com | *.susaas.com | - -| 3 wildcard certificates | 1 wildcard certificate
| -|---|---| -| \
\
\
\
\
*.us.susaas.com
*.ap.susaas.com | *.susaas.com | - -Using subdomains instead of dashes to separate stages or regions might **easy the maintenance** from a provider perspective, but it will **increase the costs** of your required Multi-Domain Wildcard SSL Certificate. Let me give you one sample. - -Let's assume you deployed your SaaS application to the eu10 and us20 region. Your sample customers ABC and XYZ subscribe to the app in both regions. - -**Scenario 1 - Subdomain per region** - ->* eu10 - abc.eu10.susaas.com
->* eu10 - xyz.eu10.susaas.com
->* us20 - abc.us20.susaas.com
->* us20 - xyz.us20.susaas.com
- -On-time **CNAME records** in your DNS zone
->* *.eu10.susaas.com -> api.cf.eu10.hana.ondemand.com
->* *.us20.susaas.com -> api.cf.us20.hana.ondemand.com - -Easy setup, requiring only two simple wildcard CNAME records pointing to the different regions. A bit more expensive, as two wildcard certificates will be required. - -[
](./images/CD_Dot.png)
-
-*Sample Setup using a subdomain-based region separation*
-
-**Scenario 2 - Regions separated by dash**
-
->* eu10 - abc-eu10.susaas.com->* eu10 - xyz-eu10.susaas.com
->* us20 - abc-us20.susaas.com
->* us20 - xyz-us20.susaas.com
- -Required CNAME records in your DNS zone - ->* abc-eu10.susaas.com -> api.cf.eu10.hana.ondemand.com
->* xyz-eu10.susaas.com -> api.cf.eu10.hana.ondemand.com
->* abc-us20.susaas.com -> api.cf.us20.hana.ondemand.com
->* xyz-us20.susaas.com -> api.cf.us20.hana.ondemand.com
- -More complicated setup, requiring **region AND customer specific CNAME records** pointing to the different customer domains in the different regions. Cheaper as only one certificate is required. - -[
](./images/CD_Dash.png)
-
-*Sample setup using a dash-based region separation*
-
-- -**Scenario 1 vs Scenario 2** - -So what you see is quite obvious! In case of dash-usage, you cannot provide simple wildcard CNAME records in your DNS zone. Instead, you need to maintain all customer routes manually. This process might be automated by respective APIs of your DNS provider but still, it's more effort compared to using wildcard records. On the other side you can save the money for an additional SSL certificate in each region. - -> **Important** - The number in both scenarios doubles, by each region you want to equip with it's own stages like abc-test-eu10.susaas.com or abc.test.eu10.susaas.com. Means you have four certificates to pay for or 8 CNAME records to maintain. - -So all not trivial and the setup completely depends on the effort you want to spend in maintaining CNAME records and the money in your pocket for wildcard certificates. Okay, so are you ready for the final confusion and a little piece of brilliancy? Read the expert-scenario - -
- -**Expert scenario - Dot separation** - -You might also combine the dot-separated regional approach with an additional wildcard domain on your app's top level. This is especially useful for customers, that don't want to have the region on the application's domain. - ->* eu10 - abc.eu10.susaas.com
-> ------- abc.susaas.com ->* us20 - abc.us20.susaas.com
-> ------- abc.susaas.com - -Making the consumer's tenant available in different regions using the same domain (e.g., abc.susaas.com), allows you to implement smart routing mechanisms as a SaaS provider. You could e.g., route customers coming from the US always to the us20 region whereas EU customer are routed to the eu10 region. - -This all happens without the consumer users even noticing it. They will always access the application using abc.susaas.com. Still, if they want access to a dedicated region, the can also call the region specific URL at any time. - -This setup requires a bit more effort, as two route mappings need to be created for each customer requiring a smart routing approach. - -[
](./images/CD_DotExpert.png)
-
-*Sample expert setup using subdomain-based region separation*
-
-- -**Expert scenario - Dash separation** - -In a dash-based approach, this is already possible without an additional certificate as you anyway only have one certificate for the *.susaas.com domain. - -From an effort perspective, also in this setup two route mappings need to be created for each customer requiring a smart routing approach - ->* eu10 - abc-eu10.susaas.com
-> ------- abc.susaas.com ->* us20 - abc-us20.susaas.com
-> ------- abc.susaas.com - -[
](./images/CD_DashExpert.png)
-
-*Sample expert setup using dash-based region separation*
-
-- -### Consumer domain - -Using a consumer's own domain like **abc.com** and providing the users access to your SaaS application via **susaas.abc.com** is also possible, but not recommended. In this case, you will need to create a new custom domain in your provider subaccount like **susaas.abc.com** and send a Certificate Signing Request (CSR) to your consumer. - -The consumer needs to sign this CSR using a trusted Certification Authority and send it back to you! Then you can activate the certificate for your consumer and map it to his SaaS instance. While this is technically possible, you will sooner or later face issues when offering this option to your consumers. - -These issues for example start with the required certificate rotations, as certificates have a fixed validity end date. While you can manage that for one or two consumers, it will be a lot of effort in case of a hundred consumers. CSRs will need to be created again and again for each of these consumers and you need to make sure to upload the new signed certificates in time! Also from a cost perspective, each new certificate will cause costs on the SAP BTP side, which you need to cross-charge to your consumers. - -Unfortunately, as of today consumers cannot share their own custom domain (which might already be registered in SAP BTP) with you as a SaaS provider. This has security related reasons and it is not yet forseeable, if a solution can be provided from a long term perspective. - -As of now, we recommend to provide your customers a subdomain of your provider's custom domain, until a potential solution is in place. - -
- -### Domain blocking - -A risk that comes with using your own provider domain for all your consumers can be seen in the following scenario. Let's assume you have a customer abc in the ap20 region. - -* abc-ap20.susaas.com - -This consumer now uses your SaaS application, to store or transmit data which from a regulatory perspective may not be communicated via the internet in a certain country. Or your consumer even uses the SaaS application for any illegal content. This might lead to a situation, in which the access to a whole domain will be blocked by regulatory bodies in a country. That means, that no consumer in that country will be able to access your application anymore! - -The only way to overcome this risk, is to use customer's own domains, which is currently not possible yet. - -
- -### Summary - -Okay, wow that was a lot of content to digest. In case there's more questionmarks then answers now, don't worry. It's not an easy topic. Just go through the chapter which you've read once again and things might become clearer. - -
- -## 4. Custom Domain Service - -Okay, so let's get started with setting up the Custom Domain service in your provider subaccount. - -3.1. To setup a custom domain in your SAP BTP provider subaccount, please add the respective entitlement in your SAP BTP Cockpit. Make sure to use the **standard (Application)** plan, as the *custom_domains* plan is deprecated and will not receive future updates. - -[
](./images/CusDom_Plans.png)
-
-3.2. After adding the entitlement to your subaccount, please subscribe to the
-
-
-
->>>>>>> Stashed changes
diff --git a/docu/4-expert/-CloudFoundry-/custom-domain-usage/files/free-advanced-domain.mtaext b/docu/4-expert/-CloudFoundry-/custom-domain-usage/files/free-advanced-domain.mtaext
new file mode 100644
index 0000000..33cbf50
--- /dev/null
+++ b/docu/4-expert/-CloudFoundry-/custom-domain-usage/files/free-advanced-domain.mtaext
@@ -0,0 +1,53 @@
+ID: susaas.freetier
+_schema-version: 3.2.0
+version: 1.0.0
+extends: susaas
+
+modules:
+ - name: susaas
+ parameters:
+ tenant-separator: '.'
+ app-domain: '
](./images/MR_MultiReg01.png?raw=true)
diff --git a/docu/4-expert/-CloudFoundry-/multiple-hana-cloud/README.md b/docu/4-expert/-CloudFoundry-/multiple-hana-cloud/README.md
index 6b5d27b..491a7e9 100644
--- a/docu/4-expert/-CloudFoundry-/multiple-hana-cloud/README.md
+++ b/docu/4-expert/-CloudFoundry-/multiple-hana-cloud/README.md
@@ -1,11 +1,15 @@
# Use multiple SAP HANA Cloud instances
-In this part of the **Expert Scope** you will get an ideo how to set up a scenario in which you do not want to share the same SAP HANA Cloud instance among all your SaaS consumers but require separate SAP HANA Cloud instances for selected or all your customers. This might for example be required for legal reasons concerning data privacy regulations.
+- ### **Kyma** ❌
+- ### **Cloud Foundry** ✅
-> **Important** - This part of of the Expert Scope has been added based on a question in the SAP Community. As the approach has not been tested extensively by our team, please make sure to test your setup end-to-end including the whole lifecycle of the container managed by the Service Manager - Create, Update, Delete!
+In this part of the **Expert Features** you will get an ideo how to set up a scenario in which you do not want to share the same SAP HANA Cloud instance among all your SaaS consumers but require separate SAP HANA Cloud instances for selected or all your customers. This might for example be required for legal reasons concerning data privacy regulations.
-1. [Setup Steps](#1-Setup-Steps)
-2. [Further Details](#2-Further-Details)
+> **Important** - This part of of the Expert Features has been added based on a question in the SAP Community. As the approach has not been tested extensively by our team, please make sure to test your setup end-to-end including the whole lifecycle of the container managed by the Service Manager - Create, Update, Delete!
+
+- [Use multiple SAP HANA Cloud instances](#use-multiple-sap-hana-cloud-instances)
+ - [1. Setup Steps](#1-setup-steps)
+ - [2. Further Details](#2-further-details)
> **Important** - The following scenario assumes that your SaaS application is running in the **same SAP BTP Region** and **SAP BTP Global Account** as the consumer-specific SAP HANA Cloud instances. Scenarios with SAP HANA Cloud instances running in other SAP BTP Regions are not supported by the approach below. For access requirements across SAP BTP Regions or SAP BTP Global Accounts, please consider manually connecting to the SAP HANA Cloud instances from within your application logic using the **@sap/hdbext** npm package. You might store the credentials of each consumer's SAP HANA Cloud instance in a Secure Store and read it when connecting from your application logic.
diff --git a/docu/4-expert/-CloudFoundry-/setup-cicd-for-project/README.md b/docu/4-expert/-CloudFoundry-/setup-cicd-for-project/README.md
index e2e78a7..4e5080e 100644
--- a/docu/4-expert/-CloudFoundry-/setup-cicd-for-project/README.md
+++ b/docu/4-expert/-CloudFoundry-/setup-cicd-for-project/README.md
@@ -1,33 +1,36 @@
# Setup CI/CD for your Project
-In this part of the **Expert Scope** you will learn how to set up the **SAP Continuous Integration and Delivery (CI/CD)** service to handle all your DevOps-related tasks like automated tests, builds, and deployments of your code changes to speed up your development and delivery cycles.
-
-
-1. [Introduction](#1-Introduction)
-2. [Setup SAP CI/CD Service](#2Setup-SAP-CI/CD-Service)
-3. [Provide SAP BTP credentials](#3-Provide-SAP-BTP-credentials)
-4. [Provide GitHub credentials](#4-Provide-GitHub-credentials)
-5. [Provide Service Broker credentials](#5-Provide-Service-Broker-credentials)
-6. [Add your repository](#6-Add-your-repository)
-7. [Create a GitHub Webhook](#7-Create-a-GitHub-Webhook)
-8. [Add the Webhook to GitHub](#8-Add-the-Webhook-to-GitHub)
-9. [Configure a CI/CD Job](#9-Configure-a-CI/CD-Job)
-10. [Create the pipeline files](#10-Create-the-pipeline-files)
-11. [Push and test](#11-Push-and-test)
-12. [Additional Unit Tests](#12-Additional-Unit-Tests)
-13. [Enhance your pipeline](#13-Enhance-your-pipeline)
-14. [Further Information](#14-Further-Information)
+- ### **Kyma** ❌
+- ### **Cloud Foundry** ✅
+
+In this part of the **Expert Features** you will learn how to set up the **SAP Continuous Integration and Delivery (CI/CD)** service to handle all your DevOps-related tasks like automated tests, builds, and deployments of your code changes to speed up your development and delivery cycles.
+
+- [Setup CI/CD for your Project](#setup-cicd-for-your-project)
+ - [1. Introduction](#1-introduction)
+ - [2. Setup SAP CI/CD Service](#2-setup-sap-cicd-service)
+ - [3. Provide SAP BTP credentials](#3-provide-sap-btp-credentials)
+ - [4. Provide GitHub credentials](#4-provide-github-credentials)
+ - [5. Provide Service Broker credentials](#5-provide-service-broker-credentials)
+ - [6. Add your repository](#6-add-your-repository)
+ - [7. Create a GitHub Webhook](#7-create-a-github-webhook)
+ - [8. Add the Webhook to GitHub](#8--add-the-webhook-to-github)
+ - [9. Configure a CI/CD Job](#9-configure-a-cicd-job)
+ - [10. Create the pipeline files](#10-create-the-pipeline-files)
+ - [11. Push and test](#11-push-and-test)
+ - [12. Additional Unit Tests](#12-additional-unit-tests)
+ - [13. Enhance your pipeline](#13-enhance-your-pipeline)
+ - [14. Further Information](#14-further-information)
## 1. Introduction
-In the following part of the **Expert Scope**, you will learn how to set up an SAP CI/CD service instance in your SAP BTP environment. You will enhance your existing project with some additional files allowing an automated build and deployment of your SaaS application to a Cloud Foundry space of your choice.
+In the following part of the **Expert Features**, you will learn how to set up an SAP CI/CD service instance in your SAP BTP environment. You will enhance your existing project with some additional files allowing an automated build and deployment of your SaaS application to a Cloud Foundry space of your choice.
To understand the basics of Continuous Integration and Delivery, please start reading the official **SAP Help** documentation ([click here](https://help.sap.com/docs/CONTINUOUS_DELIVERY/f3d64e9188f242ffb7873da5dfad4278/618ca03fdca24e56924cc87cfbb7673a.html?locale=en-US)).
[
](./images/CICD_Basics01.png?raw=true)
-Continue with the most important **Concepts**, to understand the differences between **Jobs and Builds** or the concepts of **Pipelines, Stages, and Steps**, as we will use these words throughout this part of the **Expert Scope**. You can find great explanations in the official SAP Help documentation ([click here](https://help.sap.com/docs/CONTINUOUS_DELIVERY/f3d64e9188f242ffb7873da5dfad4278/707017c681aa4bc09d0279f08115dcae.html?locale=en-US))
+Continue with the most important **Concepts**, to understand the differences between **Jobs and Builds** or the concepts of **Pipelines, Stages, and Steps**, as we will use these words throughout this part of the **Expert Features**. You can find great explanations in the official SAP Help documentation ([click here](https://help.sap.com/docs/CONTINUOUS_DELIVERY/f3d64e9188f242ffb7873da5dfad4278/707017c681aa4bc09d0279f08115dcae.html?locale=en-US))
[
](./images/CICD_Basics02.png?raw=true)
@@ -91,6 +94,7 @@ The **SAP CI/CD Service** gives you access to a selected set of the **Project "P
[
](./images/CICD_Setup05.png?raw=true)
+
## 4. Provide GitHub credentials
4.1. In the **Credentials** menu, click on **+**.
@@ -143,11 +147,11 @@ Instead of pushing your hashed API Service Broker credentials to GitHub, the cre
6.1. Navigate to the **Repository** tab in the CI/CD Service and click on **+** to add your repository.
-6.2. Provide a name for your repository like **btp-cf-cap-multitenant-susaas**.
+6.2. Provide a name for your repository like **btp-cap-multitenant-saas**.
6.3. Enter the **Repository URL** of your **forked** GitHub repository.
-> **Hint** - https://github.com/**YourUser**/btp-cf-cap-multitenant-susaas
+> **Hint** - https://github.com/**YourUser**/btp-cap-multitenant-saas
6.4. Select your GitHub credentials (**git-credentials**) created in previous steps and click **Add**.
@@ -175,7 +179,7 @@ In this and the next step, you will read the so-called Webhook Data of the repos
## 8. Add the Webhook to GitHub
-8.1. In your GitHub repository (https://github.com/**YourUser**/btp-cf-cap-multitenant-susaas) go to the **Settings** tab.
+8.1. In your GitHub repository (https://github.com/**YourUser**/btp-cap-multitenant-saas) go to the **Settings** tab.
8.2. From the navigation pane, choose **Hooks/Webhooks**.
@@ -199,15 +203,15 @@ In this and the next step, you will read the so-called Webhook Data of the repos
9.1. In the **Jobs** tab of the CI/CD service, choose **+** to create a new job.
-9.2. As **Job Name**, enter a name for your job for example **susaas-basic** or **susaas-advanced** depending on which branch you want to deploy.
+9.2. As **Job Name**, enter a name for your job for example **susaas-basic** or **susaas-advanced** depending on which Version you want to deploy.
9.3. From the **Repository** dropdown, select the configured repository.
-9.4. As **Branch**, provide the GitHub branch from which you want to receive push events (**basic** or **advanced**).
+9.4. As **Branch**, provide the GitHub **main** branch to receive push events (**basic** or **advanced**).
9.5. As **Pipeline**, choose **SAP Cloud Application Programming Model**.
-> **Hint** - You can find the stages and steps of this pipeline in the official SAP Help documentation ([click here](https://help.sap.com/docs/CONTINUOUS_DELIVERY/f3d64e9188f242ffb7873da5dfad4278/bfe48a4b12ed41868f92fa564829f752.html?locale=en-US)).
+> **Hint** - You can find the stages and steps of this pipeline in the official SAP Help documentation ([click here](https://help.sap.com/docs/continuous-integration-and-delivery/f3d64e9188f242ffb7873da5dfad4278/configure-sap-cloud-application-programming-model-job-in-your-repository?locale=en-US)).
9.6. Keep the default values in the BUILD RETENTION section.
@@ -226,19 +230,17 @@ In this and the next step, you will read the so-called Webhook Data of the repos
[
](./images/CICD_RepoStructure.png?raw=true)
-10.2. Place the provided [free-tier-cicd.mtaext](./files/free-tier-cicd.mtaext) file in the root of your project or add it to the *./configs/deployment/* directory.
+10.2. Place the provided [free-basic-cicd.mtaext](./files/free-basic-cicd.mtaext) file to the *./deploy/cf/mtaext* directory.
-> **Hint** - Take the [trial-cicd.mtaext](./files/trial-cicd.mtaext) file in case of SAP BTP Trial usage.
+> **Hint** - Take the [trial-basic-cicd.mtaext](./files/trial-basic-cicd.mtaext) file in case of SAP BTP Trial usage.
10.3. Update the **config.yaml** file in the *.pipline* directory and adjust the values of the **cloudFoundryDeploy** step based on your own environment/setup. Below you can find a sample configuration.
-
* apiEndpoint - The API endpoint of your Cloud Foundry region
* org - The target Cloud Foundry organization
* space - The target Cloud Foundry space
* mtaExtensionDescriptor - The relative path to which you saved the **mtaext file**.
-
[
](./images/CICD_ConfigSample.png?raw=true)
diff --git a/docu/4-expert/-CloudFoundry-/setup-cicd-for-project/files/config.yml b/docu/4-expert/-CloudFoundry-/setup-cicd-for-project/files/config.yml
index 2a31e56..5c10774 100644
--- a/docu/4-expert/-CloudFoundry-/setup-cicd-for-project/files/config.yml
+++ b/docu/4-expert/-CloudFoundry-/setup-cicd-for-project/files/config.yml
@@ -19,6 +19,7 @@ steps:
mtaBuild:
platform: 'CF'
+ source: ./deploy/cf/
cloudFoundryDeploy:
cfCredentialsId: cf-credentials
@@ -31,7 +32,7 @@ steps:
susaas-sb-credentials: susaas-sb-credentials
-# tmsUpload: # only relevant once you finish the SAP Cloud Transport Management Expert Scope chapter
+# tmsUpload: # only relevant once you finish the SAP Cloud Transport Management Expert Feature chapter
# nodeName: 'QA'
# credentialsId: 'tms'
# customDescription: 'TMS Upload'
\ No newline at end of file
diff --git a/docu/4-expert/-CloudFoundry-/setup-cicd-for-project/files/free-tier-cicd.mtaext b/docu/4-expert/-CloudFoundry-/setup-cicd-for-project/files/free-basic-cicd.mtaext
similarity index 100%
rename from docu/4-expert/-CloudFoundry-/setup-cicd-for-project/files/free-tier-cicd.mtaext
rename to docu/4-expert/-CloudFoundry-/setup-cicd-for-project/files/free-basic-cicd.mtaext
diff --git a/docu/4-expert/-CloudFoundry-/setup-cicd-for-project/files/trial-cicd.mtaext b/docu/4-expert/-CloudFoundry-/setup-cicd-for-project/files/trial-basic-cicd.mtaext
similarity index 100%
rename from docu/4-expert/-CloudFoundry-/setup-cicd-for-project/files/trial-cicd.mtaext
rename to docu/4-expert/-CloudFoundry-/setup-cicd-for-project/files/trial-basic-cicd.mtaext
diff --git a/docu/4-expert/-CloudFoundry-/using-sap-theme-designer/README.md b/docu/4-expert/-CloudFoundry-/using-sap-theme-designer/README.md
index da302d4..4d6527a 100644
--- a/docu/4-expert/-CloudFoundry-/using-sap-theme-designer/README.md
+++ b/docu/4-expert/-CloudFoundry-/using-sap-theme-designer/README.md
@@ -1,43 +1,35 @@
# Using SAP Theme Designer with multitenancy
-In this part of the mission you will learn how to let your consumers use the SAP Theme Designer for creating their own custom application themes.
-
-## Content
-
-[Prerequisites](#prerequsites)
-
-[1. Adding UI Theme Designer Entitlemment](#1-adding-ui-theme-designer-entitlement)
-
-[2. Adding the service to mta.yaml](#2-adding-the-service-to-mtayaml)
-
-[3. Add UI Theme Designer service as a dependency to **provisioning.js**](#3-add-ui-theme-designer-service-as-a-dependency-to-provisioningjs)
-
-[4. Rebuild and deploy your multitenant application](#4-rebuild-and-deploy-your-multitenant-application)
-
-[5. Update your tenants dependencies](#5-update-your-tenants-dependencies)
-
-[6. Open UI Theme Designer for your consumer subaccount (tenant)](#6-open-ui-theme-designer-for-your-consumer-subaccount-tenant)
-- [6.1. Add UI Theme Designer Entitlement to your consumer subaccount](#61-add-ui-theme-designer-entitlement-to-your-consumer-subaccount)
-- [6.2. Assign the roles to yourself to be able to use UI Theme Designer service](#62-assign-the-roles-to-yourself-to-be-able-to-use-ui-theme-designer-service)
-- [6.3. Modify the application endpoint ](#63-modify-the-application-endpoint)
-
-[7. Create a custom theme for your application](#7-create-a-custom-theme-for-your-application)
-- [7.1. Press Create New Theme ](#71-press-create-new-theme)
-- [7.2. Change logo of the theme](#72-change-logo-of-the-theme)
-- [7.3. Publish theme with the new logo](#73-publish-theme-with-the-new-logo)
-- [7.4 Edit your SAP UI5 Application to use your custom theme](#74-edit-your-sap-ui5-application-to-use-your-custom-theme)
-- [7.5 Build and deploy the application](#75-build-and-deploy-the-application)
-- [7.6 Go to your consumer subaccount and open your application](#76-go-to-your-consumer-subaccount-and-open-your-application)
+- ### **Kyma** ❌
+- ### **Cloud Foundry** ✅
+In this part of the mission you will learn how to let your consumers use the SAP Theme Designer for creating their own custom application themes.
+- [Using SAP Theme Designer with multitenancy](#using-sap-theme-designer-with-multitenancy)
+ - [Prerequsites](#prerequsites)
+ - [1. Adding UI Theme Designer Entitlement](#1-adding-ui-theme-designer-entitlement)
+ - [2. Adding the service to mta.yaml](#2-adding-the-service-to-mtayaml)
+ - [3. Add UI Theme Designer service as a dependency to provisioning.js](#3-add-ui-theme-designer-service-as-a-dependency-to-provisioningjs)
+ - [4. Rebuild and deploy your multitenant application](#4-rebuild-and-deploy-your-multitenant-application)
+ - [5. Update your tenants dependencies](#5-update-your-tenants-dependencies)
+ - [6. Open UI Theme Designer for your consumer subaccount (tenant)](#6-open-ui-theme-designer-for-your-consumer-subaccount-tenant)
+ - [6.1. Add UI Theme Designer Entitlement to your consumer subaccount](#61-add-ui-theme-designer-entitlement-to-your-consumer-subaccount)
+ - [6.2. Assign the roles to yourself to be able to use UI Theme Designer service](#62-assign-the-roles-to-yourself-to-be-able-to-use-ui-theme-designer-service)
+ - [6.3. Modify the application endpoint](#63-modify-the-application-endpoint)
+ - [7. Create a custom theme for your application](#7-create-a-custom-theme-for-your-application)
+ - [7.1. Press Create New Theme](#71-press-create-new-theme)
+ - [7.2. Change logo of the theme](#72-change-logo-of-the-theme)
+ - [7.3. Publish theme with the new logo](#73-publish-theme-with-the-new-logo)
+ - [7.4 Edit your SAP UI5 Application to use your custom theme](#74-edit-your-sap-ui5-application-to-use-your-custom-theme)
+ - [7.5 Build and deploy the application](#75-build-and-deploy-the-application)
+ - [7.6 Go to your consumer subaccount and open your application](#76-go-to-your-consumer-subaccount-and-open-your-application)
## Prerequsites
Before starting please make sure that you already have the following:
- Your multitenant application is deployed and running.
-> **Hint** : You might follow this section from both basic and advanced scope. This example will do deployment to the **free-tier** SAP BTP Account with basic scope.
-
+> **Hint** - You might follow this section from both Basic and Advanced Version. This example will do deployment to the **free-tier** SAP BTP Account using the Basic Version.
## 1. Adding UI Theme Designer Entitlement
Before we start we need to add UI Theme Designer service entitlement to both **consumer** and **provider** subaccounts to be able to
@@ -51,120 +43,30 @@ Repeat the same steps for your **consumer** subaccount.
Go to your mta.yaml file of your application and append the UI Theme Designer service to the resources section of your mta.yaml, so that it gets generated when you make a new deployment.
-After that please make sure that you put your service instance definition to the required section of **susaas** and **susaas-srv**
-modules so that service binding is also generated when you make a new deployment.
-
-
+After that please make sure that you put your service instance definition to the required section of **susaas** and **susaas-srv** modules so that service binding is also generated when you make a new deployment.
```yml
_schema-version: '3.2'
ID: susaas
version: 0.0.1
-parameters:
- enable-parallel-deployments: true
- autoscalerMinInstance: 1
- autoscalerMaxInstance: 2
-
-build-parameters:
- before-all:
- - builder: custom
- commands:
- - npx -p @sap/cds-dk cds build --profile production
-
modules:
# --------------------- APPROUTER MODULE ---------------------
- name: susaas
# ------------------------------------------------------------
type: approuter.nodejs
path: app/approuter
- build-parameters:
- builder: npm-ci
- ignore: [ 'node_modules/', 'default-env.json', 'manifest*.yml' ]
- parameters:
- app-name: susaas-${space}
- disk-quota: 256MB
- memory: 128MB
- tenant-separator: '-'
- app-domain: ${app-name}.${default-domain}
- keep-existing-routes: true
- properties:
- TENANT_HOST_PATTERN: '^(.*)${tenant-separator}${app-domain}'
requires:
- - name: susaas-destination
- - name: susaas-html5-repo-runtime
- name: susaas-uaa
- - name: susaas-srv-api
- name: susaas-theming # Here the theme designer bounded to approuter
- provides:
- - name: susaas-approuter
- properties:
- app-url: ${default-url}
- application: ${app-name}
- tenant-separator: ${tenant-separator}
- app-domain: ${app-domain}
# --------------------- SERVER MODULE ------------------------
- name: susaas-srv
# ------------------------------------------------------------
type: nodejs
- path: gen/srv
- build-parameters:
- builder: npm-ci
- ignore: ['node_modules/', 'default-*.json', 'manifest*.yml']
- parameters:
- app-name: susaas-srv-${space}
- memory: 256MB
- disk-quota: 1024MB
- properties:
- tenantSeparator: ~{susaas-approuter/tenant-separator}
- appDomain: ~{susaas-approuter/app-domain}
- brokerName: ~{susaas-api-sb-srv/app-name}
- srvUrl: 'https://${app-name}.${default-domain}'
- brokerUrl: ~{susaas-api-sb-srv/srv-url}
- approuterUrl: ~{susaas-approuter/app-url}
- appName: ~{susaas-approuter/application}
requires:
- name: susaas-uaa
- - name: susaas-credstore
- parameters:
- config:
- authorization:
- default_permissions:
- - read
- - decrypt
- - encrypt
- - list
- - name: susaas-logging
- - name: susaas-registry
- - name: susaas-service-manager
- - name: susaas-destination
- - name: susaas-cis-central
- - name: susaas-html5-repo-runtime
- - name: susaas-alert-notification
- - name: susaas-api-sb-srv
- - name: susaas-approuter
- name: susaas-theming ## Here the theme designer service instance bounded to SRV
- - name: susaas-autoscaler
- parameters:
- config:
- instance_min_count: 1
- instance_max_count: 2
- scaling_rules:
- - {"metric_type": "memoryutil","threshold": 80,"operator": ">=","adjustment": "+1"}
- - {"metric_type": "memoryutil","threshold": 60,"operator": "<","adjustment": "-1"}
- - {"metric_type": "cpu","threshold": 80,"operator": ">=","adjustment": "+1"}
- - {"metric_type": "cpu","threshold": 30,"operator": "<","adjustment": "-1"}
- - name: susaas-com-hdi-container
- group: SERVICE_REPLACEMENTS
- properties:
- key: susaas-com-hdi-container
- service: '~{susaas-com-container-name}'
- provides:
- - name: susaas-srv-api
- properties:
- srv-url: ${default-url}
-
...
resources:
@@ -178,11 +80,10 @@ resources:
service-plan: standard
```
-> **Hint**: You might check this example [**theme-designer-mta.yaml**](./theme-designer.mta.yaml) file to see an example of
-> an mta deployment file. This deployment file has been copied from the current basic branch, and only theme designer service instance
-> and bindings has been added to it.
-## 3. Add UI Theme Designer service as a dependency to [provisioning.js](https://github.com/SAP-samples/btp-cf-cap-multitenant-susaas/blob/basic/srv/provisioning.js)
+> **Hint**: You might check this example [**theme-designer-mta.yaml**](./files/theme-designer.mta.yaml) file to see an example of an mta deployment file. This deployment file has been copied from the current basic branch, and only theme designer service instance and bindings has been added to it.
+
+## 3. Add UI Theme Designer service as a dependency to [provisioning.js](https://github.com/SAP-samples/btp-cap-multitenant-saas/blob/main/code/srv/srv/provisioning.js)
To be able to reuse the Theme Designer service within our consumer subaccounts, we need to add the **UI Theme Designer** service instance to the dependencies callback of our multitenant application.
@@ -192,14 +93,15 @@ Go to your **srv/provisioning.js** file and make the changes shown below.
service.on('dependencies', async (req, next) => {
let dependencies = await next();
const services = xsenv.getServices({
- registry: { tag: 'SaaS' },
html5Runtime: { tag: 'html5-apps-repo-rt' },
destination: { tag: 'destination' },
themeDesigner: { tag: 'sap-theming'} // Add this line
});
+
dependencies.push({ xsappname: services.html5Runtime.uaa.xsappname });
dependencies.push({ xsappname: services.destination.xsappname });
dependencies.push({ xsappname: services.themeDesigner.uaa.xsappname}); // Add this line
+
console.log("SaaS Dependencies:", JSON.stringify(dependencies));
return dependencies;
});
@@ -207,33 +109,32 @@ Go to your **srv/provisioning.js** file and make the changes shown below.
## 4. Rebuild and deploy your multitenant application
-You need to build and deploy your application to activate the changes you have done on the steps before.
+You need to build and deploy your application to activate the changes you have done on the steps before. Run the commands below to build and deploy your application again.
-Run the commands below to build and deploy your application again.
+> **Important** - Please ensure you change your *deploy/cf/mta.yaml* file accordingly as explained above.
```sh
-mbt build -e configs/deployment/free-tier.mtaext
-cf deploy mta_archives/*
+mbt build -e ./mtaext/free-basic-private.mtaext
+cf deploy mta_archives/susaas-0.0.1.mtar
```
## 5. Update your tenants dependencies
-You need to update the dependencies of your existing **tenants** because you do not have UI theme designer as a
-dependency yet, since you have subscribed to this multitenant application earlier then UI Theme Designer modification.
+You need to update the dependencies of your existing **tenants** because you do not have UI theme designer as a dependency yet, since you have subscribed to this multitenant application earlier then UI Theme Designer modification.
-> **Hint** : If you do not have an already subscribed consumer subaccount, you might directly create a new subaccount and subscribe to the application. You may skip the **Subscription Management Steps** below.
+> **Hint** - If you do not have an already subscribed consumer subaccount, you might directly create a new subaccount and subscribe to the application. You may skip the **Subscription Management Steps** below.
-Go to your **provider subaccount**, assign the roles for **Subscription Management Dashboard** as documented [here](https://help.sap.com/docs/BTP/65de2977205c403bbc107264b8eccf4b/434be695f9e946ccb4c28911dd1e16d0.html).
+Go to your **provider subaccount**, assign the roles for **Subscription Management Dashboard** as documented [here](https://help.sap.com/docs/btp/sap-business-technology-platform/using-subscription-management-dashboard?locale=en-US).
Then open the **Subscription Management Dashboard** from your provider subaccount, and update **all** existing tenants as shown below.
-
[
](./images/subscription-management-update.jpg?raw=true)
## 6. Open UI Theme Designer for your consumer subaccount (tenant)
### 6.1. Add UI Theme Designer Entitlement to your consumer subaccount
+
In your subaccount, go to **Entitlements** to add an entitlement for the UI Theme Designer service. To do so, click **Configure Entitlements** Add Service Plans and add the UI Theme Designer with plan standard to the relevant subaccount. Then click **Save**.
### 6.2. Assign the roles to yourself to be able to use UI Theme Designer service
@@ -246,15 +147,14 @@ Administrators need to add required roles to their role collections and assign t
- Publisher (sap-theming): Publish custom themes (but no editing)
- Viewer (sap-theming): View custom themes in UI theme designer
-So create a role collection as described [here](https://help.sap.com/docs/SAP_S4HANA_Cloud_for_Customer_Payments/b2f6973263b04162a5dfb97d30d2ee4a/913c74be68474887b9498892235f12a6.html) called : **Theme Admin**.
+So create a role collection as described [here](https://help.sap.com/docs/SAP_S4HANA_Cloud_for_Customer_Payments/b2f6973263b04162a5dfb97d30d2ee4a/913c74be68474887b9498892235f12a6.html?locale=en-US) called : **Theme Admin**.
Then go to your **Theme Admin** role collection and add the roles as shown below.
[
](./images/assign-roles.jpg?raw=true)
-
-
### 6.3. Modify the application endpoint
+
Go to your tenant subaccount, and then click on **Go to Application**.
[
](./images/go-to-app.jpg?raw=true)
@@ -271,15 +171,13 @@ Replace your application endpoint in the browser with : *
](./images/create-new-theme.jpg?raw=true)
### 7.2. Change logo of the theme
-To be able to change logo, press first company logo section and upload your logo.
-Then press refresh to see the logo you have uploaded.
+To be able to change logo, press first company logo section and upload your logo. Then press refresh to see the logo you have uploaded.
[
](./images/change-logo.jpg?raw=true)
@@ -290,7 +188,8 @@ Press on the **Theme** button on top left, then press **Save & Publish** as show
[
](./images/publish-theme.jpg?raw=true)
Then give the choice **Theme ID** : custom_horizon (you will need this ID later).
-Optional: You can also give **sap_horizon** as fallback theme id.
+
+Optional: You can also provide **sap_horizon** as fallback theme id.
[
](./images/theme-id.jpg?raw=true)
@@ -298,7 +197,7 @@ And press **Save & Publish** again to finalize saving.
### 7.4 Edit your SAP UI5 Application to use your custom theme
-Go to your [index.html](https://github.com/SAP-samples/btp-cf-cap-multitenant-susaas/blob/basic/app/uimodule/webapp/index.html) file in your application and edit as described below.
+Go to your [launchpad.html](https://github.com/SAP-samples/btp-cap-multitenant-saas/blob/main/code/app/launchpad.html) file in your application and edit as described below.
[
](./images/modify-index.jpg?raw=true)
@@ -307,22 +206,16 @@ These properties must be added or modified :
- **data-sap-ui-theme-roots**='{"custom_horizon" : "/comsapuitheming.runtime/themeroot/v1/UI5"}'
- **data-sap-ui-versionedLibCss**="true"
- **data-sap-ui-resourceroots** ='{
- "susaas.assessments": "./public/assessments",
- "susaas.projects": "./public/projects",
- "susaas.admin.projects": "./admin/projects",
- "susaas.admin.users": "./admin/users",
"susaas":"/" -> add this line
}'
-> **Hint**: Please notice that the theme id you put into **data-sap-ui-theme** and **data-sap-ui-theme-roots** properties
-should be the same theme id you have filled in [this step.](#73-publish-theme-with-the-new-logo)
+> **Hint** - Please notice that the theme id you put into **data-sap-ui-theme** and **data-sap-ui-theme-roots** properties should be the same theme id you have filled in [this step.](#73-publish-theme-with-the-new-logo)
-For detailed information about step, see the [official documentation](https://help.sap.com/docs/BTP/09f6818d8e064537973102d6289e2aca/80642ec6cc3c4b7cb840e17dfec8fd8d.html).
+For detailed information about step, see the [official documentation](https://help.sap.com/docs/btp/ui-theme-designer/running-custom-theme-via-sapui5-bootstrap-configuration?locale=en-US).
### 7.5 Build and deploy the application
-Do the same steps describe again as on the [step](#4-rebuild-and-deploy-your-multitenant-application).
-Build and deploy your application again to push the changes to your applcation.
+Do the same steps describe again as on the [step](#4-rebuild-and-deploy-your-multitenant-application). Build and deploy your application again to push the changes to your applcation.
### 7.6 Go to your consumer subaccount and open your application
diff --git a/docu/4-expert/-CloudFoundry-/using-sap-theme-designer/theme-designer.mta.yaml b/docu/4-expert/-CloudFoundry-/using-sap-theme-designer/files/theme-designer.mta.yaml
similarity index 68%
rename from docu/4-expert/-CloudFoundry-/using-sap-theme-designer/theme-designer.mta.yaml
rename to docu/4-expert/-CloudFoundry-/using-sap-theme-designer/files/theme-designer.mta.yaml
index 4e2ed7d..6bc2d66 100644
--- a/docu/4-expert/-CloudFoundry-/using-sap-theme-designer/theme-designer.mta.yaml
+++ b/docu/4-expert/-CloudFoundry-/using-sap-theme-designer/files/theme-designer.mta.yaml
@@ -3,6 +3,7 @@ ID: susaas
version: 0.0.1
parameters:
+ deploy_mode: html5-repo
enable-parallel-deployments: true
autoscalerMinInstance: 1
autoscalerMaxInstance: 2
@@ -11,21 +12,19 @@ build-parameters:
before-all:
- builder: custom
commands:
- ### Deployment w/o csv sample files ###
- - npx -p @sap/cds-dk cds build --profile production
-
- ### Deployment w/ csv sample files ###
- #- npx -p @sap/cds-dk cds build --profile production,csv
+ - npm install --include=dev --prefix=../../code
+ - npx -p @sap/cds-dk@7 cds build -in ../../code --profile production
modules:
# --------------------- APPROUTER MODULE ---------------------
- name: susaas
# ------------------------------------------------------------
type: approuter.nodejs
- path: app/approuter
+ path: ../../code/router
build-parameters:
- builder: npm-ci
- ignore: [ 'node_modules/', 'default-env.json', 'manifest*.yml' ]
+ builder: custom
+ commands: []
+ ignore: [ '.DS_Store', 'node_modules/', 'default-env.json', 'manifest*.yml' ]
parameters:
app-name: susaas-${space}
disk-quota: 256MB
@@ -42,18 +41,20 @@ modules:
- name: susaas-srv-api
- name: susaas-theming
provides:
- - name: susaas-approuter
+ - name: susaas-router-api
properties:
app-url: ${default-url}
application: ${app-name}
tenant-separator: ${tenant-separator}
app-domain: ${app-domain}
+
+
# --------------------- WEBAPP DEPLOYER ----------------------
- - name: webapp_deployer
+ - name: susaas-app-deployer
# ------------------------------------------------------------
type: com.sap.application.content
- path: app/deployer
+ path: ../../code/app/html5-deployer
requires:
- name: susaas-html5-repo-host
parameters:
@@ -61,45 +62,108 @@ modules:
build-parameters:
build-result: resources
requires:
- - name: susaas-ui
- artifacts:
- - susaasui.zip
- target-path: resources/
+ - name: sapsusaasuipublicflp
+ target-path: resources/
+ artifacts:
+ - sapsusaasuipublicflp.zip
+ - name: sapsusaasuiadminprojects
+ target-path: resources/
+ artifacts:
+ - sapsusaasuiadminprojects.zip
+ - name: sapsusaasuiadminusers
+ target-path: resources/
+ artifacts:
+ - sapsusaasuiadminusers.zip
+ - name: sapsusaasuipublicprojects
+ target-path: resources/
+ artifacts:
+ - sapsusaasuipublicprojects.zip
+ - name: sapsusaasuipublicassessments
+ target-path: resources/
+ artifacts:
+ - sapsusaasuipublicassessments.zip
- # --------------------- UI MODULE ----------------------------
- - name: susaas-ui
+
+ # --------------------- UI MODULES ----------------------------
+ #
# ------------------------------------------------------------
+ - name: sapsusaasuipublicflp
+ type: html5
+ path: ../../code/app/ui-public-flp
+ build-parameters:
+ build-result: dist
+ builder: custom
+ ignore: [ 'node_modules/', 'default-env.json', 'manifest*.yml' ]
+ commands:
+ - npm run build
+ supported-platforms: []
+
+ - name: sapsusaasuiadminprojects
+ type: html5
+ path: ../../code/app/ui-admin-projects
+ build-parameters:
+ build-result: dist
+ builder: custom
+ ignore: [ 'node_modules/', 'default-env.json', 'manifest*.yml' ]
+ commands:
+ - npm run build
+ supported-platforms: []
+
+ - name: sapsusaasuiadminusers
+ type: html5
+ path: ../../code/app/ui-admin-users
+ build-parameters:
+ build-result: dist
+ builder: custom
+ ignore: [ 'node_modules/', 'default-env.json', 'manifest*.yml' ]
+ commands:
+ - npm run build
+ supported-platforms: []
+
+ - name: sapsusaasuipublicprojects
+ type: html5
+ path: ../../code/app/ui-public-projects
+ build-parameters:
+ build-result: dist
+ builder: custom
+ ignore: [ 'node_modules/', 'default-env.json', 'manifest*.yml' ]
+ commands:
+ - npm run build
+ supported-platforms: []
+
+ - name: sapsusaasuipublicassessments
type: html5
- path: app/uimodule
+ path: ../../code/app/ui-public-assessments
build-parameters:
build-result: dist
builder: custom
- ignore: [ 'node_modules/', 'mta_archives/', 'default-env.json', 'manifest*.yml' ]
+ ignore: [ 'node_modules/', 'default-env.json', 'manifest*.yml' ]
commands:
- - npm ci
- - npm run build:cf
+ - npm run build
supported-platforms: []
+
# --------------------- SERVER MODULE ------------------------
- name: susaas-srv
# ------------------------------------------------------------
type: nodejs
- path: gen/srv
+ path: ../../code/gen/srv
build-parameters:
- builder: npm-ci
- ignore: ['node_modules/', 'default-*.json', 'manifest*.yml']
+ builder: npm
+ ignore: [ '.DS_Store', 'node_modules/', 'default-*.json', 'manifest*.yml']
parameters:
app-name: susaas-srv-${space}
memory: 256MB
disk-quota: 1024MB
+ command: node ./node_modules/@sap/cds/bin/cds-serve
properties:
- tenantSeparator: ~{susaas-approuter/tenant-separator}
- appDomain: ~{susaas-approuter/app-domain}
+ tenantSeparator: ~{susaas-router-api/tenant-separator}
+ appDomain: ~{susaas-router-api/app-domain}
brokerName: ~{susaas-api-sb-srv/app-name}
srvUrl: 'https://${app-name}.${default-domain}'
brokerUrl: ~{susaas-api-sb-srv/srv-url}
- approuterUrl: ~{susaas-approuter/app-url}
- appName: ~{susaas-approuter/application}
+ approuterUrl: ~{susaas-router-api/app-url}
+ appName: ~{susaas-router-api/application}
requires:
- name: susaas-uaa
- name: susaas-credstore
@@ -114,12 +178,12 @@ modules:
- name: susaas-logging
- name: susaas-registry
- name: susaas-service-manager
+ - name: susaas-service-manager-admin
- name: susaas-destination
- - name: susaas-cis-central
- name: susaas-html5-repo-runtime
- name: susaas-alert-notification
- name: susaas-api-sb-srv
- - name: susaas-approuter
+ - name: susaas-router-api
- name: susaas-theming
- name: susaas-autoscaler
parameters:
@@ -134,20 +198,20 @@ modules:
- name: susaas-com-hdi-container
group: SERVICE_REPLACEMENTS
properties:
- key: susaas-com-hdi-container
- service: '~{susaas-com-container-name}'
+ key: com-hdi-container
+ service: '~{com-container-name}'
provides:
- name: susaas-srv-api
properties:
srv-url: ${default-url}
- # --------------------- COMMON DB MODULE --------------------
+ # --------------------- COMMON DB MODULE ---------------------
- name: susaas-db-com
# ------------------------------------------------------------
type: hdb
- path: gen/db-com
+ path: ../../code/gen/db-com
build-parameters:
- ignore: ['node_modules/', 'default-*.json', 'manifest*.yml']
+ ignore: [ '.DS_Store', 'node_modules/', 'default-*.json', 'manifest*.yml']
parameters:
app-name: susaas-db-com-${space}
memory: 256MB
@@ -155,62 +219,66 @@ modules:
requires:
- name: susaas-com-hdi-container
+
# ----------- BROKER MODULE (OSBAPI Implementation) ----------
- name: susaas-api-sb
# ------------------------------------------------------------
type: nodejs
- path: broker/
+ path: ../../code/broker/
build-parameters:
- builder: npm-ci
- ignore: ['node_modules/', 'default-*.json', 'manifest*.yml']
+ builder: custom
+ commands: []
+ ignore: [ '.DS_Store', 'node_modules/', 'default-*.json', 'manifest*.yml']
parameters:
app-name: susaas-api-sb-${space}
- memory: 64MB
- disk-quota: 265MB
+ memory: 128MB
+ disk-quota: 512MB
properties:
- SBF_BROKER_CREDENTIALS_HASH: >
- {
- "broker-user": "