diff --git a/docu/1-discover/1-discover-tutorial-target/README.md b/docu/1-discover/1-discover-tutorial-target/README.md index 899e763..5747255 100644 --- a/docu/1-discover/1-discover-tutorial-target/README.md +++ b/docu/1-discover/1-discover-tutorial-target/README.md @@ -1,5 +1,8 @@ # Discover the Tutorial Target +- **Kyma** ✅ +- **Cloud Foundry** ✅ + In this tutorial, you will learn how to set up a multitenant Software as a Service (SaaS) application using CAP in your SAP Business Technology Platform (SAP BTP) environment. This use-case can be deployed to the **SAP BTP, Cloud Foundry** and also SAP's managed Kubernetes offering, the **SAP BTP, Kyma Runtime**. You are flexible to choose which runtime suits your needs or skills. > **Hint** - You will find separate step-by-step tutorials in case the deployment steps differentiate. Ensure to check the chapter introductions, as those will clearly indicate whether a the content targets a specific runtime! Feel free to ignore any content or chapters not related to your chosen runtime! 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 d9edd5d..7eb7c4c 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 @@ -1,5 +1,8 @@ # The Basics of SAP BTP, Cloud Foundry, Kyma and CAP +- **Kyma** ✅ +- **Cloud Foundry** ✅ + The **SAP Business Technology Platform (SAP BTP)** is an integrated offering comprised of four technology portfolios: database and data management, application development and integration, analytics, and intelligent technologies. The platform offers users the ability to turn data into business value, compose end-to-end business processes, and build and extend SAP applications quickly. - [The Basics of SAP BTP, Cloud Foundry, Kyma and CAP](#the-basics-of-sap-btp-cloud-foundry-kyma-and-cap) diff --git a/docu/1-discover/3-partners-sap-btp-ecosystem/README.md b/docu/1-discover/3-partners-sap-btp-ecosystem/README.md index f4c3b01..f3e6db0 100644 --- a/docu/1-discover/3-partners-sap-btp-ecosystem/README.md +++ b/docu/1-discover/3-partners-sap-btp-ecosystem/README.md @@ -1,5 +1,8 @@ # Partners in SAP BTP Ecosystem +- **Kyma** ✅ +- **Cloud Foundry** ✅ + To learn more about how SAP BTP is helping partners and businesses succeed, check out the [Accelerating Innovation and Time to Market with SAP BTP](https://news.sap.com/2022/04/idc-study-on-sap-btp-partners-accelerate-innovation/) article, some [recent partner success stories](https://www.sap.com/products/technology-platform/partners.html) or, if you’re interested in SAP BTP software partnership opportunities with SAP, please visit [SAP PartnerEdge, Build](https://www.sap.com/partners/partner-program/build.html) for more information. Let us also use the chance to provide you with some more input about **SAP Industry Cloud** in this context. diff --git a/docu/1-discover/4-get-idea-saas-applications/README.md b/docu/1-discover/4-get-idea-saas-applications/README.md index 349841a..02039ec 100644 --- a/docu/1-discover/4-get-idea-saas-applications/README.md +++ b/docu/1-discover/4-get-idea-saas-applications/README.md @@ -1,5 +1,8 @@ # Get the idea of a SaaS application +- **Kyma** ✅ +- **Cloud Foundry** ✅ + This part of the tutorial is to explain the ideas and advantages of **Software as a Service (SaaS)** applications. You might have heard of SaaS in combination with other abbreviations like **IaaS** (Infrastructure as a Service) and **PaaS** (Platform as a Service). Without the intention to cover all these topics in the greatest detail, let's at least try to cover the basics here. For more information please feel free to consult your favorite search engine provider, which will deliver a ton of results for the search terms above. SaaS applications are part of our daily life and not just in a B2B world but also in B2C environments. If you think of subscription services like Office365 which is used by a lot of private customers, this is a perfect example of Software as a Service in which Microsoft provides you the well-known Microsoft Office tools as web applications (and as a desktop version if you like). All you need to do is sign up for an account and you're ready to go. No installation, configuration, or updates are required. So let's see how the idea of SaaS evolved throughout the last years. diff --git a/docu/1-discover/5-understand-btp-multitenancy/README.md b/docu/1-discover/5-understand-btp-multitenancy/README.md index e3f273d..06898e5 100644 --- a/docu/1-discover/5-understand-btp-multitenancy/README.md +++ b/docu/1-discover/5-understand-btp-multitenancy/README.md @@ -1,5 +1,8 @@ # Understand SAP BTP Multitenancy +- **Kyma** ✅ +- **Cloud Foundry** ✅ + In SAP BTP, you can develop and run multitenant applications that can be accessed by multiple consumers (tenants) through a dedicated URL. In this sample scenario, we decided to implement the solution based on a standardized toolset including the SAP Cloud Application Programming (CAP) Model. ## Context diff --git a/docu/1-discover/6-whats-new/README.md b/docu/1-discover/6-whats-new/README.md index b4d724b..82ab1a1 100644 --- a/docu/1-discover/6-whats-new/README.md +++ b/docu/1-discover/6-whats-new/README.md @@ -1,5 +1,8 @@ # What's new +- **Kyma** ✅ +- **Cloud Foundry** ✅ + On this section of the tutorial, you will find a summary of all new features after the initial publication of the tutorial and the GitHub repository. | Date | Title | Branch | Short description | diff --git a/docu/2-basic/0-introduction-basic-version/README.md b/docu/2-basic/0-introduction-basic-version/README.md index 3da4f33..38d5acb 100644 --- a/docu/2-basic/0-introduction-basic-version/README.md +++ b/docu/2-basic/0-introduction-basic-version/README.md @@ -1,7 +1,7 @@ # Introduction to the Basic Version -- ### **Kyma** ✅ -- ### **Cloud Foundry** ✅ +- **Kyma** ✅ +- **Cloud Foundry** ✅ The **Basic Version** of the sample application will provide you with the core elements required for a Software as a Service (SaaS) application on SAP Business Technology Platform (SAP BTP). diff --git a/docu/2-basic/1-understand-repo-structure/README.md b/docu/2-basic/1-understand-repo-structure/README.md index ecf185b..04b6e01 100644 --- a/docu/2-basic/1-understand-repo-structure/README.md +++ b/docu/2-basic/1-understand-repo-structure/README.md @@ -1,7 +1,7 @@ # Understand the Repository Structure -- ### **Kyma** ✅ -- ### **Cloud Foundry** ✅ +- **Kyma** ✅ +- **Cloud Foundry** ✅ This part of the tutorial will briefly outline the structure of **code** directory, so you're comfortable navigating through the provided GitHub repository. If you are targeting a Cloud Foundry deployment, please ignore the Kubernetes related artifacts like **Dockerfiles**, which are not required for your deployment. diff --git a/docu/2-basic/10-troubleshooting/README.md b/docu/2-basic/10-troubleshooting/README.md index af20920..1d3d0be 100644 --- a/docu/2-basic/10-troubleshooting/README.md +++ b/docu/2-basic/10-troubleshooting/README.md @@ -1,7 +1,7 @@ # Troubleshooting -- ### **Kyma** ✅ -- ### **Cloud Foundry** ✅ +- **Kyma** ✅ +- **Cloud Foundry** ✅ In this section of the **Basic Version** you can find troubleshooting information that might help you in case of errors or issues. The content of this section will be continuously enhanced in the future. diff --git a/docu/2-basic/2-prepare-provider-subaccount/README.md b/docu/2-basic/2-prepare-provider-subaccount/README.md index 5b03f2b..bd285ca 100644 --- a/docu/2-basic/2-prepare-provider-subaccount/README.md +++ b/docu/2-basic/2-prepare-provider-subaccount/README.md @@ -1,7 +1,7 @@ # Prepare the Provider Subaccount -- ### **Kyma** ✅ -- ### **Cloud Foundry** ✅ +- **Kyma** ✅ +- **Cloud Foundry** ✅ In this chapter, you will learn how to prepare your SAP BTP Provider Subaccount for the deployment of the sample SaaS solution by assigning the required entitlements and setting up the foundational components. This includes a SAP HANA Cloud instance which you need to share with your **Cloud Foundry** environment or your **Kyma Cluster** before deployment. 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 69739b3..54886c6 100644 --- a/docu/2-basic/3-cf-build-deploy-application/README.md +++ b/docu/2-basic/3-cf-build-deploy-application/README.md @@ -1,7 +1,7 @@ # Cloud Foundry - Build and deploy the SaaS application -- ### **Kyma** ❌ -- ### **Cloud Foundry** ✅ +- **Kyma** ❌ +- **Cloud Foundry** ✅ **Important** - This part of the tutorial is required for **Cloud Foundry** deployments only! @@ -101,7 +101,7 @@ $ cf deploy mta_archives/susaas_0.0.1.mtar -e ./mtaext/free-tier-private.mtaext 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 **\-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 **\-susaas-credstore** instance or use the **Manage Instance** button. [](./images/CS_Service.png?raw=true) @@ -133,7 +133,7 @@ Provide the e-mail address (Username) and password (Value) of an SAP BTP user wh As Value please provide the **Plaintext Password** of your API broker user. This password is required when registering the API broker in any of your consumer subaccounts during automation. -> **Hint** - You created this password in step 1.4 of "[Prepare the SaaS Application for deployment](#1-Prepare-the-SaaS-Application-for-deployment)". +> **Hint** - You created this password in step 1.4 of "[Prepare the SaaS Application for deployment](#1-Prepare-the-SaaS-Application-for-deployment)".
[](./images/SB_PlainText.png?raw=true) As a Username please use the value **broker-user**. 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 814a3c9..21a7352 100644 --- a/docu/2-basic/3-kyma-build-docker-images/README.md +++ b/docu/2-basic/3-kyma-build-docker-images/README.md @@ -1,7 +1,7 @@ # Kyma - Build, Pack and Push your Docker Images -- ### **Kyma** ✅ -- ### **Cloud Foundry** ❌ +- **Kyma** ✅ +- **Cloud Foundry** ❌ **Important** - This part of the tutorial is required for **Kyma** deployments only! @@ -25,7 +25,7 @@ Let us have a brief look at the tool prerequisites, which are essential to build If you are facing any issues during the following steps of our tutorial, please feel free to consult the excellent **Developer Tutorial** on **Deploy Your CAP Application on SAP BTP Kyma Runtime**. It describes similar steps and will get you covered in great detail, in case you get stuck in our sample scenario. -https://developers.sap.com/mission.btp-deploy-cap-kyma.html +[https://developers.sap.com/mission.btp-deploy-cap-kyma.html](https://developers.sap.com/mission.btp-deploy-cap-kyma.html) ## 1. Prerequisites @@ -138,7 +138,7 @@ These components will be containerized in Docker Images in the following steps. 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) as Container Image Prefix placeholder. If you use the GitHub Container Registry, the prefix will look similar to **ghcr.io/\** (e.g. ghcr.io/johndoe). All generated Docker Images will be automatically prefixed with this label! +> **Hint** - If you use e.g. DockerHub as a Container Registry, please put in your **username** (e.g., johndoe) as Container Image Prefix placeholder. If you use the GitHub Container Registry, the prefix will look similar to **ghcr.io/\** (e.g. ghcr.io/johndoe). All generated Docker Images will be automatically prefixed with this label! > **Hint** - Using devices with ARM chips (e.g., Apple M1) the build process involving Cloud Native Buildpacks might take several minutes. Please do not immediately cancel the build if things appear to be stuck, but wait some time for the process to continue (especially while the SBOM is being generated)! @@ -171,7 +171,7 @@ Building **Dockerfiles** for Kubernetes workloads is not always easy. Especially Once again, I highly suggest to have a quick break and scroll through the excellent blog post of Maximilian Streifeneder, who gets you covered on the topic of Paketo as well as some nice little tricks how to further analyze generated Docker Images! -https://blogs.sap.com/2023/03/07/surviving-and-thriving-with-the-sap-cloud-application-programming-model-deployment-to-sap-btp-kyma-runtime/ +[https://blogs.sap.com/2023/03/07/surviving-and-thriving-with-the-sap-cloud-application-programming-model-deployment-to-sap-btp-kyma-runtime/](https://blogs.sap.com/2023/03/07/surviving-and-thriving-with-the-sap-cloud-application-programming-model-deployment-to-sap-btp-kyma-runtime/) Docker Images created using Paketo and Cloud Native Buildpacks are secure, efficient, production-ready and come with a lot of features, which are hard to provided using Dockerfiles and would require much more manual effort. To get an idea of the features provided by Cloud Native Buildpacks, check out the official documentation ([click here](https://buildpacks.io/features/)). To learn about the general concepts behind Cloud Native Buildpacks (turning your source-code into a read-to-use Docker Image), check out the respective documentation ([click here](https://buildpacks.io/docs/concepts/)). @@ -186,7 +186,7 @@ As the API Service is based on CAP and Node.js, for the initial build or any cha This simplifies the containerization process and allows you to build a Docker Image without the necessity of maintaining a separate Dockerfile for Node.js workloads. During the build process, Paketo will take the content of the *gen/api* directory and put it into the working directory of a Node.js Docker Image. This image is based on the latest and stable Cloud Native Buildpacks. -**Npm script to build the Docker Image using Paketo** ([/deploy/kyma/package.json](../../../deploy/kyma/package.json)) +**Npm script to build the Docker Image using Paketo** ([*/deploy/kyma/package.json*](../../../deploy/kyma/package.json)) ```json "build:api": "pack build sap-demo/susaas-api --path ../../code/gen/api --builder paketobuildpacks/builder:base --buildpack gcr.io/paketo-buildpacks/nodejs -e BP_LAUNCHPOINT=./node_modules/@sap/cds/bin/cds-serve.js" @@ -203,7 +203,7 @@ As the central Backend Service is also based on CAP, for the initial build or an Doing so (as for the API Service), a Docker Image can be build without having to maintain a separate Dockerfile. During the build process, Paketo will take the content of the *gen/srv* directory, and place it into the working directory a Node.js Docker Image. Again, this image is based on the latest and stable Cloud Native Buildpacks. -**Npm script to build the Docker Image using Paketo** ([/deploy/kyma/package.json](../../../deploy/kyma/package.json)) +**Npm script to build the Docker Image using Paketo** ([*/deploy/kyma/package.json*](../../../deploy/kyma/package.json)) ```json "build:srv": "pack build sap-demo/susaas-srv --path ../../code/gen/srv --builder paketobuildpacks/builder:base --buildpack gcr.io/paketo-buildpacks/nodejs -e BP_LAUNCHPOINT=./node_modules/@sap/cds/bin/cds-serve.js" @@ -220,7 +220,7 @@ Therefore, we created a tiny Dockerfile which is using the official SAP Docker I > **Hint** - The package.json file is part of the directory for local testing purposes only. As the SAP-managed Docker Image *sapse/approuter* already contains a package.json file, we will reuse the start script of this SAP-provided package.json scripts. -**Dockerfile based on sapse/approuter Docker Image** ([/code/router/Dockerfile](../../../code/router/Dockerfile)) +**Dockerfile based on sapse/approuter Docker Image** ([*/code/router/Dockerfile*](../../../code/router/Dockerfile)) ```Dockerfile # Image based on SAP provided sapse/approuter image @@ -242,7 +242,7 @@ COPY . . CMD [ "npm", "start" ] ``` -**Build Docker Image based on Dockerfile above** ([/deploy/kyma/package.json](../../../deploy/kyma/package.json)) +**Build Docker Image based on Dockerfile above** ([*/deploy/kyma/package.json*](../../../deploy/kyma/package.json)) > **Hint** - This following npm script will build a Docker Image based on the Dockerfile located in the */code/router* directory and will tag it with *sap-demo/susaas-router*. "sap-demo" has to be replaced by the prefix also used in step 3.1, if you want to run this command standalone. @@ -259,7 +259,7 @@ For the API Service Broker (which is actually just a generic Node.js workload ba This way (as for the API and SaaS Backend Service), a Docker Image can be build without maintaining a separate Dockerfile. During the build process, Paketo will take the content of the *broker* directory, and place it into the working directory of a Node.js Docker Image. This Docker Image is again based on the latest Cloud Native Buildpacks. -**Npm script to build the Docker Image using Paketo** ([/deploy/kyma/package.json](../../../deploy/kyma/package.json)) +**Npm script to build the Docker Image using Paketo** ([*/deploy/kyma/package.json*](../../../deploy/kyma/package.json)) ```json "build:broker": "pack build sap-demo/susaas-broker --path ../../code/broker --builder paketobuildpacks/builder:base --buildpack gcr.io/paketo-buildpacks/nodejs -e BP_LAUNCHPOINT=./start.js" @@ -276,27 +276,27 @@ As this Docker Image is maintained by SAP, there is no need to make use of Cloud The *resources* folder (within the *code/app/html5-deployer* directory) contains the zipped UI5 modules (which you need to build upfront using the *npm run ui:apps* script - [see here](#2-build-your-components)). If you followed all previous tutorial steps, the respective zip files should already exist, as the respective command will automatically run the *build* scripts in the *package.json* files of our UI5 modules. -**Npm script to trigger the build of a single UI module** ([/deploy/kyma/package.json](../../../deploy/kyma/package.json)) +**Npm script to trigger the build of a single UI module** ([*/deploy/kyma/package.json*](../../../deploy/kyma/package.json)) ```json "ui:admin-projects": "npm run build:copy --prefix ../../code/app/ui-admin-projects/" ``` -**Npm scripts to build a UI module and copy zip to html5 app deployer** ([/code/app/ui-admin-projects/package.json](../../../code/app/ui-admin-projects/package.json)) +**Npm scripts to build a UI module and copy zip to html5 app deployer** ([*/code/app/ui-admin-projects/package.json*](../../../code/app/ui-admin-projects/package.json)) ```json "scripts": { "build:copy": "npm run build && npm run copy", "build": "ui5 build preload --clean-dest --config ui5-deploy.yaml --include-task=generateCachebusterInfo", "copy": "shx mkdir -p ../html5-deployer/resources/ && shx cp -rf ./dist/*.zip ../html5-deployer/resources/" -}, +} ``` Similar to the Application Router, the Dockerfile residing in the *code/app/html5-deployer* folder, copies the *html5-deployer* directory content into the working directory of the resulting Docker Image, which is based on the SAP-managed *sapse/html5-app-deployer* image. > **Hint** - The package.json file is part of the *code/app/html5-deployer* directory for local testing purposes only. As the Docker Base Image *sapse/html5-app-deployer* already contains a corresponding package.json file, we will reuse the start script of this SAP-provided package.json. -**Dockerfile based on sapse/html5-app-deployer Docker Image** ([/code/app/html5-deployer/Dockerfile](../../../code/app/html5-deployer/Dockerfile)) +**Dockerfile based on sapse/html5-app-deployer Docker Image** ([*/code/app/html5-deployer/Dockerfile*](../../../code/app/html5-deployer/Dockerfile)) ```Dockerfile # Image based on SAP provided sapse/html5-app-deployer image @@ -318,7 +318,7 @@ COPY . . CMD [ "npm", "start" ] ``` -**Build Docker Image based on Dockerfile above** ([/deploy/kyma/package.json](../../../deploy/kyma/package.json)) +**Build Docker Image based on Dockerfile above** ([*/deploy/kyma/package.json*](../../../deploy/kyma/package.json)) ```json "build:html5-deployer": "docker build -t sap-demo/susaas-html5-deployer ../../code/app/html5-deployer" @@ -332,7 +332,7 @@ As the data model of the shared database container is also based on CAP, for the After running the CDS build (compiling the CDS files of our CAP Backend, CAP API, Tenant and shared data model), the required Docker Image (containing an HDI deployer for the shared data model) is build using Paketo and Cloud Native Buildpacks. This simplifies the build process and allows us to build a Docker Image without the necessity of maintaining a separate Dockerfile. During the build process, Paketo will take the content of the *gen/db-com* directory and place it into the working directory of a Node.js Docker Image. This image is based on the latest Cloud Native Buildpacks. -**Npm script to build the Docker Image using Paketo** ([/deploy/kyma/package.json](../../../deploy/kyma/package.json)) +**Npm script to build the Docker Image using Paketo** ([*/deploy/kyma/package.json*](../../../deploy/kyma/package.json)) ```json "build:db-com": "pack build sap-demo/susaas-db-com --path ../../code/gen/db-com --builder paketobuildpacks/builder:base --buildpack gcr.io/paketo-buildpacks/nodejs -e BP_LAUNCHPOINT=./node_modules/@sap/hdi-deploy/deploy.js" @@ -349,7 +349,7 @@ To allow Helm to pull your Docker Images during the deployment process, you need After all your Docker Images are build using **Cloud Native Buildpacks** or **SAP Standard Images**, you can push them to your Container Registry. To do so, please ensure you successfully logged in to your registry of choice (*docker login*) before running the following npm script. -> **Hint** - If you use e.g. DockerHub as a Container Registry, please put in your **username** (e.g., johndoe) as Container Image Prefix placeholder. If you use the GitHub Container Registry, the prefix will look similar to **ghcr.io/\** (e.g. ghcr.io/johndoe). All generated Docker Images will be automatically prefixed with this label! +> **Hint** - If you use e.g. DockerHub as a Container Registry, please put in your **username** (e.g., johndoe) as Container Image Prefix placeholder. If you use the GitHub Container Registry, the prefix will look similar to **ghcr.io/\** (e.g. ghcr.io/johndoe). All generated Docker Images will be automatically prefixed with this label! ```sh # Run in ./deploy/kyma # diff --git a/docu/2-basic/3-kyma-deploy-application/README.md b/docu/2-basic/3-kyma-deploy-application/README.md index 21bea0c..7c9b105 100644 --- a/docu/2-basic/3-kyma-deploy-application/README.md +++ b/docu/2-basic/3-kyma-deploy-application/README.md @@ -1,7 +1,7 @@ # Kyma - Deploy the SaaS application -- ### **Kyma** ✅ -- ### **Cloud Foundry** ❌ +- **Kyma** ✅ +- **Cloud Foundry** ❌ **Important** - This part of the tutorial is required for **Kyma** deployments only! @@ -18,18 +18,18 @@ Before you deploy the sample application to your **SAP BTP, Kyma Runtime**, plea If you are facing any issues during the following steps of our tutorial, please feel free to consult the excellent **Developer Tutorial** on **Deploy Your CAP Application on SAP BTP Kyma Runtime**. It describes similar steps and will get you covered in great detail, in case you get stuck in our sample scenario. -https://developers.sap.com/mission.btp-deploy-cap-kyma.html +[https://developers.sap.com/mission.btp-deploy-cap-kyma.html](https://developers.sap.com/mission.btp-deploy-cap-kyma.html) ## 1. Introduction The deployment of the Sustainable Saas solution to your SAP BTP Kyma Cluster is handled by [Helm](https://helm.sh/). To learn more about the basic concepts of Helm, visit the respective chapter of the tutorial ([click here](../7-kyma-resources-helm/README.md)). Repeating myself, I also suggest to read and inhale the brilliant blog post of Maximilian Streifeneder on the topics of Kyma, Helm, Paketo and a lot more! It will give you a great overview and introduction if you are new to the Kubernetes, Docker and Kyma world! -https://blogs.sap.com/2023/03/07/surviving-and-thriving-with-the-sap-cloud-application-programming-model-deployment-to-sap-btp-kyma-runtime/ +[https://blogs.sap.com/2023/03/07/surviving-and-thriving-with-the-sap-cloud-application-programming-model-deployment-to-sap-btp-kyma-runtime/](https://blogs.sap.com/2023/03/07/surviving-and-thriving-with-the-sap-cloud-application-programming-model-deployment-to-sap-btp-kyma-runtime/) Furthermore, if you are facing any issues during the following steps of our tutorial, please feel free to consult the excellent **Developer Tutorial** on **Deploy Your CAP Application on SAP BTP Kyma Runtime**. It describes similar steps and will get you covered in great detail, in case you get stuck in our sample scenario. -https://developers.sap.com/mission.btp-deploy-cap-kyma.html +[https://developers.sap.com/mission.btp-deploy-cap-kyma.html](https://developers.sap.com/mission.btp-deploy-cap-kyma.html) Before you proceed with the following steps, please make sure you have successfully built your Docker Images and pushed them to the Container Registry of your choice (e.g., Docker Hub or GitHub). Helm will not make use of your local Docker Images, but will pull the latest Images from the provided registry and deploy them to your Kyma Cluster. @@ -129,7 +129,7 @@ kubelogin version v1.26.0 2.5. Once you downloaded the *kubeconfig.yaml* file, please store it as a file named **config** (! without any file name extension !) in your hidden *$HOME/.kube* directory. Kubectl will check this **hidden** directory for an available configuration file named **config**. This is probably the most convenient way to provide your Cluster access details to kubectl. -> **Hint** - In Windows, the directory is e.g., C:\Users\\\\.kube +> **Hint** - In Windows, the directory is e.g., C:\Users\\\\.kube Alternatively, you can also configure the location of your configuration file in the environment variable **KUBECONFIG** or by adding the kubectl parameter *--kubeconfig* to any kubectl command (which is obviously a bit cumbersome). @@ -213,7 +213,7 @@ Let's get started with the preparation of our **Helm deployment** or **Helm inst 3.2. In your personal **values-private.yaml** file, please provide values for the following parameters, based on your own environment and the Container Registry being used. - **global** +**global** * imagePullSecret - Name of a Image Pull Secret if required. > **Hint** - This value needs to contain the reference to a potential Image Pull Secret of your Container Registry. If you're using a free Docker Hub account and public Docker Images, this property can be left unchanged (empty object). Otherwise, please make sure to create a Kyma **Secret** containing your imagePullSecret and provide the reference to your Secret here. @@ -235,47 +235,48 @@ Let's get started with the preparation of our **Helm deployment** or **Helm inst > In a productive SAP BTP landscape, your **shootName** will always starts with a letter like *a1b2c3* or with the prefix **c-** like c-1b2c3d4*. - **router** +**router** - * image.repository - Provide the registry details of your [Application Router](../3-kyma-build-docker-images/README.md#3-create-your-docker-images) Container Image like \/susaas-router if your images are stored in Docker Hub or ghcr.io/\/susaas-router in case of GitHub. + * image.repository - Provide the registry details of your [Application Router](../3-kyma-build-docker-images/README.md#3-create-your-docker-images) Container Image like \/susaas-router if your images are stored in Docker Hub or ghcr.io/\/susaas-router in case of GitHub. * image.tag - Provide the tag of your container image if you do not want to use the latest image. - **srv** +**srv** - * image.repository - Provide the registry details of your [Backend Service](../3-kyma-build-docker-images/README.md#3-create-your-docker-images) Container Image repository like \/susaas-srv. + * image.repository - Provide the registry details of your [Backend Service](../3-kyma-build-docker-images/README.md#3-create-your-docker-images) Container Image repository like \/susaas-srv. * image.tag - Provide the tag of your container image if you do not want to use the latest image. - **api** +**api** - * image.repository - Provide the registry details of your [API Service](../3-kyma-build-docker-images/README.md#3-create-your-docker-images) Container Image repository like \/susaas-api + * image.repository - Provide the registry details of your [API Service](../3-kyma-build-docker-images/README.md#3-create-your-docker-images) Container Image repository like \/susaas-api * image.tag - Provide the tag of your container image if you do not want to use the latest image. - **broker** +**broker** - * image.repository - Provide the registry details of your [API Service Broker](../3-kyma-build-docker-images/README.md#3-create-your-docker-images) Container Image repository like \/susaas-broker. + * image.repository - Provide the registry details of your [API Service Broker](../3-kyma-build-docker-images/README.md#3-create-your-docker-images) Container Image repository like \/susaas-broker. * image.tag - Provide the tag of your container image if you do not want to use the latest image. * config.serviceId & planId(s) - Generate and provide unique GUIDs for your service plans and the broker itself. - > **Important** - We recommend to generate custom GUIDs using your command line or available online generators. You can run the following script from the *code/broker* directory, which will generate new GUIDs as part of a new */code/broker/catalog-private.json* file which can be used for this requirement. This file can remain in your directory for your reference and will not be committed to GitHub. + > **Important** - We recommend to generate custom GUIDs using your command line or available online generators. You can run the following script from the *code/broker* directory, which will generate new GUIDs as part of a new */code/broker/catalog-private.json* file which can be used for this requirement. This file can remain in your directory for your reference and will not be committed to GitHub.
+ > + > **Run in ./code/broker** > ```sh - > # Run in ./code/broker # > cp catalog.json catalog-private.json > npx --yes -p @sap/sbf gen-catalog-ids catalog-private.json > cat catalog-private.json > ``` - **hana_deployer** +**hana_deployer** - * image.repository - Provide the registry details of your [HDI Container Deployer](../3-kyma-build-docker-images/README.md#3-create-your-docker-images) Container Image repository like \/susaas-db-com. + * image.repository - Provide the registry details of your [HDI Container Deployer](../3-kyma-build-docker-images/README.md#3-create-your-docker-images) Container Image repository like \/susaas-db-com. * image.tag - Provide the tag of your container image if you do not want to use the latest image. - **html5_apps_deployer** +**html5_apps_deployer** - * image.repository - Provide the registry details of your [HTML5 Apps Deployer](../3-kyma-build-docker-images/README.md#3-create-your-docker-images) Container Image repository like \/susaas-html5-deployer. + * image.repository - Provide the registry details of your [HTML5 Apps Deployer](../3-kyma-build-docker-images/README.md#3-create-your-docker-images) Container Image repository like \/susaas-html5-deployer. * image.tag - Provide the tag of your container image if you do not want to use the latest image. - **xsuaa** +**xsuaa** * parameters.oauth2-configuration.redirect-urls - Please provide your default Cluster Domain including a wildcard subdomain prefix ("*."). Keep the **localhost** redirects for local testing purposes. @@ -332,7 +333,7 @@ While we could have skipped the whole part of building your own Docker Images an 4.1. If not there yet, please first of all, deploy a **SAP Alert Notification Service** instance to the Kyma Namespace of choice. -4.2. To do so, please copy or rename the provided [*values-private.sample.yaml*](../../../deploy/kyma/charts/alert-notification/values-private.sample.yaml) sample file in the *deploy/kyma/charts/alert-notification/* directory to **values-private.yaml**. This file will not be committed to GitHub due to the **-private** suffix. +4.2. To do so, please copy or rename the provided [*values-private.sample.yaml*](../../../deploy/kyma/charts/alert-notification/values-private.sample.yaml) sample file (in the *deploy/kyma/charts/alert-notification/* directory) to **values-private.yaml**. This file will not be committed to GitHub due to the **-private** suffix. 4.3. In your new **values-private.yaml** file, provide a valid email address which will act as destination for Alert Notification messages. @@ -352,7 +353,7 @@ alert_notification: destination: john.doe@example.org ``` -4.2. Save your changes and deploy a new Alert Notification Service Instance to your desired Kyma Namespace, by running the following **Helm** command from within the */deploy/kyma* directory. +4.4. Save your changes and deploy a new Alert Notification Service Instance to your desired Kyma Namespace, by running the following **Helm** command from within the */deploy/kyma* directory. > **Hint** - There can only be one Alert Notification Service instance per Kyma Namespace (or Cloud Foundry Space). Given this restriction, SAP Alert Notification Service is deployed as a standalone Helm installation in our example. @@ -366,7 +367,7 @@ helm install alert-notification ./charts/alert-notification -f ./charts/alert-no helm install alert-notification ./charts/alert-notification -f ./charts/alert-notification/values-private.yaml -n default ``` -4.3. After the Alert Notification Service has been deployed (wait for a confirmation in the console or check the Helm Release status in the Kyma Dashboard), please run the following command from within the *deploy/kyma* directory to deploy the Sustainable SaaS sample application to a namespace of your choice. +4.5. After the Alert Notification Service has been deployed (wait for a confirmation in the console or check the Helm Release status in the Kyma Dashboard), please run the following command from within the *deploy/kyma* directory to deploy the Sustainable SaaS sample application to a namespace of your choice. > **Hint** - Feel free to add the *--debug* parameter to get some more verbose output if you're interested what's happening under the hood! @@ -378,7 +379,7 @@ helm install ./charts/sustainable-saas -f ./charts/sustainable-saa helm install susaas ./charts/sustainable-saas -f ./charts/sustainable-saas/values-private.yaml -n default ``` -4.4. If you want to make your application to make use of the SAP Alert Notification Service, please include a few additional lines in your **values-private.yaml** file before starting the deployment. This will generate a new Service Binding between the Alert Notification instance and your SaaS Backend Service. +4.6. If you want to make your application to make use of the SAP Alert Notification Service, please include a few additional lines in your **values-private.yaml** file before starting the deployment. This will generate a new Service Binding between the Alert Notification instance and your SaaS Backend Service. ```yaml srv: @@ -390,7 +391,7 @@ srv: serviceInstanceFullname: alert-notification ``` -4.5. Start the deployment to your Kyma Cluster by running the following **helm** command. +4.7. Start the deployment to your Kyma Cluster by running the following **helm** command. ```sh # Run in ./deploy/kyma # @@ -410,29 +411,29 @@ helm upgrade ./charts/sustainable-saas --install -f ./charts/susta helm upgrade susaas ./charts/sustainable-saas --install -f ./charts/sustainable-saas/values-private.yaml -n default ``` -4.6. The deployment of the Helm Release to your Kyma cluster, will take a few minutes. +4.8. The deployment of the Helm Release to your Kyma cluster, will take a few minutes. -4.7. You can use this time to switch back to your Kyma Dashboard, where you can monitor the installation/deployment progress and respective objects being instantiated. Once you see the following four **Pods** in **Running** state, your deployment finished successfully. +4.9. You can use this time to switch back to your Kyma Dashboard, where you can monitor the installation/deployment progress and respective objects being instantiated. Once you see the following four **Pods** in **Running** state, your deployment finished successfully. > **Trivia** - We're kind of mixing up the terms Deployment/Installation/Release in this tutorial. [](./images/PodOverview.png?raw=true) -4.8. You can also check the successful deployment of your application in the **Apps** section of the Kyma Dashboard. Here you can find all **Helm Releases**. +4.10. You can also check the successful deployment of your application in the **Apps** section of the Kyma Dashboard. Here you can find all **Helm Releases**. [](./images/HelmOverview.png?raw=true) -4.9. For any further updates of the Helm Release, you must now use the *helm upgrade* command (already mentioned above). +4.11. For any further updates of the Helm Release, you must now use the *helm upgrade* command (already mentioned above). ```sh # Run in ./deploy/kyma # -helm upgrade ./charts/sustainable-saas -f ./charts/sustainable-saas/values-private.yaml -n +helm upgrade ./charts/sustainable-saas -f ./charts/sustainable-saas/values-private.yaml -n # Example helm upgrade susaas ./charts/sustainable-saas -f ./charts/sustainable-saas/values-private.yaml -n default ``` -4.10. To undeploy/uninstall a Helm Release, you can use the following command. +4.12. To undeploy/uninstall a Helm Release, you can use the following command. > **Important** - Please make sure to check the respective **Undeploy** chapter of the documentation first! Uninstalling a SaaS application with existing subscribers, can result in corrupt Service Instance setups which are very cumbersome to resolve. @@ -452,7 +453,7 @@ The (Helm) Release Name, is the value following the *helm install* command. You ```sh # Run in ./deploy/kyma # -helm install -dev ./charts/sustainable-saas -f ./charts/sustainable-saas/values-private.yaml -n +helm install -dev ./charts/sustainable-saas -f ./charts/sustainable-saas/values-private.yaml -n # Example helm install susaas-dev ./charts/sustainable-saas -f ./charts/sustainable-saas/values-private.yaml -n default diff --git a/docu/2-basic/4-subscribe-consumer-subaccount/README.md b/docu/2-basic/4-subscribe-consumer-subaccount/README.md index 155972e..eb65517 100644 --- a/docu/2-basic/4-subscribe-consumer-subaccount/README.md +++ b/docu/2-basic/4-subscribe-consumer-subaccount/README.md @@ -1,7 +1,7 @@ # Subscribe a Tenant Subaccount -- ### **Kyma** ✅ -- ### **Cloud Foundry** ✅ +- **Kyma** ✅ +- **Cloud Foundry** ✅ In this part of the tutorial, you will learn how to subscribe your first Tenant Subaccount and how to create a first administrator user for your Subscriber Tenant. @@ -28,7 +28,7 @@ In this part of the tutorial, you will learn how to subscribe your first Tenant 1.4. Select the **Sustainable SaaS** service from the dropdown list. -> **Hint** - In case of multiple deployments in the SAP BTP region (e.g., different Cloud Foundry Spaces or different Kyma Namespaces), make sure to use the correct service offering by checking the unique Service Id format in case of Kyma **\-\-\** and in case of Cloud Foundry **susaas-\-\**. +> **Hint** - In case of multiple deployments in the SAP BTP region (e.g., different Cloud Foundry Spaces or different Kyma Namespaces), make sure to use the correct service offering by checking the unique Service Id format in case of Kyma **\-\-\** and in case of Cloud Foundry **susaas-\-\**. **Kyma** @@ -42,13 +42,13 @@ In this part of the tutorial, you will learn how to subscribe your first Tenant 1.6. In the Kyma scenario, you can now define a **custom subdomain** for your Subscriber Tenant. Please make sure to understand this feature before making use of it. If you leave this field blank, the URL of your Subscriber Tenant will be created in the following format. -**\-\-router-\.\.kyma.ondemand.com**
-e.g., subscriber-c3b2a1-susaas-router-default.a1b2c3.kyma.ondemand.com +> **\-\-router-\.\.kyma.ondemand.com**
+> 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). -**\.\.kyma.ondemand.com**
-e.g., subscriber.a1b2c3.kyma.ondemand.com +> **\.\.kyma.ondemand.com**
+> 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! @@ -67,7 +67,7 @@ Once you subscribed to the SaaS sample application from a Tenant Subaccount, you 2.2. Therefore, go to the **Instances and Subscriptions** menu and click on **Create** again. Select the new **Sustainable SaaS API** service from the list. -> **Hint** - In case of multiple deployments in the same SAP BTP region (e.g., different Cloud Foundry Space or Kyma Namespace), make sure to use the correct service offering by checking the Service Id format in Kyma **\-api-\-\**) or in Cloud Foundry **susaas-api-\-\**. +> **Hint** - In case of multiple deployments in the same SAP BTP region (e.g., different Cloud Foundry Space or Kyma Namespace), make sure to use the correct service offering by checking the Service Id format in Kyma **\-api-\-\**) or in Cloud Foundry **susaas-api-\-\**. **Kyma** @@ -115,7 +115,7 @@ Once the SaaS subscription was successful and you created a new API Service Brok 3.1. To give the first Tenant administrator access to the SaaS instance, please **temporarily** assign the **Susaas Administrator** role collection to your own user to finish the onboarding process in the Tenant Subaccount. This is the only time a **temporary** assignment of a role collection in the SAP BTP Cockpit takes place to complete the onboarding process. -Make sure to select the correct role collection if you deployed the SaaS sample application multiple times in the same SAP BTP region. For example in Kyma, the format in parenthesis is as follows - **\-\** and in Cloud Foundry it contains the **Space** name. +Make sure to select the correct role collection if you deployed the SaaS sample application multiple times in the same SAP BTP region. For example in Kyma, the format in parenthesis is as follows - **\-\** and in Cloud Foundry it contains the **Space** name. **Kyma** 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 38aa030..aea65a8 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,7 +1,7 @@ # Push data to the SaaS API -- ### **Kyma** ✅ -- ### **Cloud Foundry** ✅ +- **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. diff --git a/docu/2-basic/6-test-the-application/README.md b/docu/2-basic/6-test-the-application/README.md index e9290be..1abe367 100644 --- a/docu/2-basic/6-test-the-application/README.md +++ b/docu/2-basic/6-test-the-application/README.md @@ -1,7 +1,7 @@ # Test the application -- ### **Kyma** ✅ -- ### **Cloud Foundry** ✅ +- **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. diff --git a/docu/2-basic/7-explore-the-components/README.md b/docu/2-basic/7-explore-the-components/README.md index 87b512d..45d71b1 100644 --- a/docu/2-basic/7-explore-the-components/README.md +++ b/docu/2-basic/7-explore-the-components/README.md @@ -1,7 +1,7 @@ # Explore the application components -- ### **Kyma** ✅ -- ### **Cloud Foundry** ✅ +- **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. 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 f4ecc71..51dfac2 100644 --- a/docu/2-basic/7-explore-the-components/components/HelperClasses.md +++ b/docu/2-basic/7-explore-the-components/components/HelperClasses.md @@ -1,7 +1,7 @@ # Deep Dive into Helper Classes -- ### **Kyma** ✅ -- ### **Cloud Foundry** ✅ +- **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. 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 8d4c979..e077e09 100644 --- a/docu/2-basic/7-explore-the-components/components/Multitenancy.md +++ b/docu/2-basic/7-explore-the-components/components/Multitenancy.md @@ -1,7 +1,7 @@ # Deep Dive into Multitenancy -- ### **Kyma** ✅ -- ### **Cloud Foundry** ✅ +- **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. 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 d8bc5ab..fde47ad 100644 --- a/docu/2-basic/7-explore-the-components/components/ServiceBrokers.md +++ b/docu/2-basic/7-explore-the-components/components/ServiceBrokers.md @@ -1,7 +1,7 @@ # Deep Dive into Service Brokers -- ### **Kyma** ✅ -- ### **Cloud Foundry** ✅ +- **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. 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 2bbf153..ef60c9f 100644 --- a/docu/2-basic/7-explore-the-components/components/SharedContainer.md +++ b/docu/2-basic/7-explore-the-components/components/SharedContainer.md @@ -1,7 +1,7 @@ # Shared Database Container -- ### **Kyma** ✅ -- ### **Cloud Foundry** ✅ +- **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. diff --git a/docu/2-basic/7-kyma-resources-helm/README.md b/docu/2-basic/7-kyma-resources-helm/README.md index c4d70e0..c52f6f3 100644 --- a/docu/2-basic/7-kyma-resources-helm/README.md +++ b/docu/2-basic/7-kyma-resources-helm/README.md @@ -1,7 +1,7 @@ # Helm Charts and Kyma resources -- ### **Kyma** ✅ -- ### **Cloud Foundry** ❌ +- **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. 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 07954c7..98a75dd 100644 --- a/docu/2-basic/7-kyma-resources-helm/components/HelmCharts.md +++ b/docu/2-basic/7-kyma-resources-helm/components/HelmCharts.md @@ -1,7 +1,7 @@ # Helm Charts -- ### **Kyma** ✅ -- ### **Cloud Foundry** ❌ +- **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. @@ -224,7 +224,7 @@ Templates in Helm Charts are files that define how resources should be deployed > **Hint** - (*) Helm Template Language definition according to [Helm official documentation](https://helm.sh/docs/chart_template_guide/functions_and_pipelines/): "While we talk about the "Helm template language" as if it is Helm-specific, it is actually a combination of the Go template language, some extra functions, and a variety of wrappers to expose certain objects to the templates. Many resources on Go templates may be helpful as you learn about templating." -[./code/chart/templates](../../../../deploy/kyma/charts/sustainable-saas/templates/) directory contains the templates of the Helm Chart. +[*/code/chart/templates/*](../../../../deploy/kyma/charts/sustainable-saas/templates/) directory contains the templates of the Helm Chart. [](./images/HELM_Chart_Temp_Dir.png?raw=true) 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 907eb27..1920d83 100644 --- a/docu/2-basic/7-kyma-resources-helm/components/ResourceOverview.md +++ b/docu/2-basic/7-kyma-resources-helm/components/ResourceOverview.md @@ -1,7 +1,7 @@ # Resource Overview -- ### **Kyma** ✅ -- ### **Cloud Foundry** ❌ +- **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. @@ -644,7 +644,7 @@ Authorization Policies are required to secure workloads in your Service Mesh bas - The request has passed through [Istio](#istio-service-mesh) Ingress Gateway and tries to call a */-/cds/** path. This requirement is fulfilled by all requests arriving in the Kyma Cluster through the public internet, as the CAP Provisioning or Extensibility endpoints will be directly called from either SAP BTP or developers deploying an extension. -- The request is originating from our Application Router. As we are using mTLS communication within the Cluster, Istio will automatically extract the identity of the source (in this case our Application Router) and place it into the *source.principal* property. In case of mTLS communication within the Service Mesh, the principal value is based on the [Service Account](#service-account) assigned to origin workload and has the following standardized format (\/ns/\/sa/\) while *ns* means namespace and *sa* means [Service Account](#service-account). +- The request is originating from our Application Router. As we are using mTLS communication within the Cluster, Istio will automatically extract the identity of the source (in this case our Application Router) and place it into the *source.principal* property. In case of mTLS communication within the Service Mesh, the principal value is based on the [Service Account](#service-account) assigned to origin workload and has the following standardized format (\/ns/\/sa/\) while *ns* means namespace and *sa* means [Service Account](#service-account). ```yaml @@ -818,8 +818,8 @@ spec: To identify the issuer and jwksUri details in case of XSUAA usage, you can follow the below format. Please make sure to provide the Subdomain and Region of your SAP BTP Provider Subaccount. -**issuer** - https://\.authentication.\.hana.ondemand.com/oauth/token
-**jwksUri** - https://\.authentication.\.hana.ondemand.com/token_keys +**issuer** - https://\.authentication.\.hana.ondemand.com/oauth/token
+**jwksUri** - https://\.authentication.\.hana.ondemand.com/token_keys ### Service Entry 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 9033e88..c6e6f4d 100644 --- a/docu/2-basic/7-kyma-resources-helm/components/TemplateDetails.md +++ b/docu/2-basic/7-kyma-resources-helm/components/TemplateDetails.md @@ -1,7 +1,7 @@ # Template Details -- ### **Kyma** ✅ -- ### **Cloud Foundry** ❌ +- **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. @@ -353,9 +353,9 @@ To guarantee that no request can reach the API Service workloads without passing - name: x-jwt-assertion ``` -- An Istio **Authorization Policy** finally ensures, that the API Service workloads can only be reached by requests providing a specific Issuer and Subject (sub) claim as part of the previously validated JWT token. This can be handled by checking the requestPrincipals property, which is provided in the following structure \/\. +- An Istio **Authorization Policy** finally ensures, that the API Service workloads can only be reached by requests providing a specific Issuer and Subject (sub) claim as part of the previously validated JWT token. This can be handled by checking the requestPrincipals property, which is provided in the following structure \/\. - > **Hint** - In this sample the JWT token issuer has to match the **token endpoint** of the provider XSUAA tenant (like https://sap-demo.authentication.us20.hana.ondemand.com/oauth/token) and the Subject has to contain the appname of the API XSUAA Service Instance prefixed with "sb-". The default structure of the Subject in this sample is **sb-\-api-\** and has to be provided in the *values.yaml* file (like sb-susaas-api-default). + > **Hint** - In this sample the JWT token issuer has to match the **token endpoint** of the provider XSUAA tenant (like https://sap-demo.authentication.us20.hana.ondemand.com/oauth/token) and the Subject has to contain the appname of the API XSUAA Service Instance prefixed with "sb-". The default structure of the Subject in this sample is **sb-\-api-\** and has to be provided in the *values.yaml* file (like sb-susaas-api-default). ```yaml apiVersion: security.istio.io/v1beta1 diff --git a/docu/2-basic/8-unsubscribe-consumer-subaccount/README.md b/docu/2-basic/8-unsubscribe-consumer-subaccount/README.md index 4fd10b6..0c63c6d 100644 --- a/docu/2-basic/8-unsubscribe-consumer-subaccount/README.md +++ b/docu/2-basic/8-unsubscribe-consumer-subaccount/README.md @@ -1,7 +1,7 @@ # Unsubscribe from a Consumer Subaccount -- ### **Kyma** ✅ -- ### **Cloud Foundry** ✅ +- **Kyma** ✅ +- **Cloud Foundry** ✅ > **Important** - If you are planning to setup the **Advanced Version** next, please consider this part of the tutorial optional! diff --git a/docu/2-basic/9-undeploy-saas-application/README.md b/docu/2-basic/9-undeploy-saas-application/README.md index 3f77707..a5d562f 100644 --- a/docu/2-basic/9-undeploy-saas-application/README.md +++ b/docu/2-basic/9-undeploy-saas-application/README.md @@ -1,7 +1,7 @@ # Undeploy the SaaS Application -- ### **Kyma** ✅ -- ### **Cloud Foundry** ✅ +- **Kyma** ✅ +- **Cloud Foundry** ✅ > **Important** - If you are planning to setup the **Advanced Version** next, please consider this part of the tutorial optional! diff --git a/docu/3-advanced/0-introduction-advanced-version/README.md b/docu/3-advanced/0-introduction-advanced-version/README.md index f7387ad..4ebce3b 100644 --- a/docu/3-advanced/0-introduction-advanced-version/README.md +++ b/docu/3-advanced/0-introduction-advanced-version/README.md @@ -1,7 +1,7 @@ # Advanced Version Introduction -- ### **Kyma** ✅ -- ### **Cloud Foundry** ✅ +- **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. diff --git a/docu/3-advanced/1-prepare-provider-subaccount/README.md b/docu/3-advanced/1-prepare-provider-subaccount/README.md index 80595b6..18f4f3d 100644 --- a/docu/3-advanced/1-prepare-provider-subaccount/README.md +++ b/docu/3-advanced/1-prepare-provider-subaccount/README.md @@ -1,7 +1,7 @@ # Prepare the Provider Subaccount -- ### **Kyma** ✅ -- ### **Cloud Foundry** ✅ +- **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**. @@ -52,7 +52,7 @@ Please check the below details on these additional entitlements required for the ## 3. SAP S/4HANA System -> **Hint** - If you do not have access to an SAP S/4HANA system, you can also use the provided HTTP sample requests (located in the [*code/test/http*](../../../code/test/http) directory), to inject some mock data into your SaaS application, leveraging the SaaS API from a subscriber perspective. +> **Hint** - If you do not have access to an SAP S/4HANA system, you can also use the provided HTTP sample requests (located in the */code/test/http/* directory), to inject some mock data into your SaaS application, leveraging the SaaS API from a subscriber perspective. 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. 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 49a949f..6061d9c 100644 --- a/docu/3-advanced/3-push-data-s4hana-system/README.md +++ b/docu/3-advanced/3-push-data-s4hana-system/README.md @@ -1,7 +1,7 @@ # Push data from SAP S/4HANA system -- ### **Kyma** ✅ -- ### **Cloud Foundry** ✅ +- **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. 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 e415ea4..4650913 100644 --- a/docu/3-advanced/4-cf-integrate-api-management/README.md +++ b/docu/3-advanced/4-cf-integrate-api-management/README.md @@ -1,7 +1,7 @@ # Integrate SAP API Management -- ### **Kyma** ❌ -- ### **Cloud Foundry** ✅ +- **Kyma** ❌ +- **Cloud Foundry** ✅ **Important** - This part of the tutorial is required for **Cloud Foundry** deployments only! 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 39b0cfe..34e1341 100644 --- a/docu/3-advanced/4-kyma-integrate-api-management/README.md +++ b/docu/3-advanced/4-kyma-integrate-api-management/README.md @@ -1,7 +1,7 @@ # Integrate SAP API Management -- ### **Kyma** ✅ -- ### **Cloud Foundry** ❌ +- **Kyma** ✅ +- **Cloud Foundry** ❌ **Important** - This part of the tutorial is required for **Kyma** deployments only! @@ -47,7 +47,7 @@ While Cloud Foundry offers a very convenient integration option using so-called 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. -3.1. Below you can see the required configuration for the API Management Integration. You can find a respective sample in the provided [./files/values-apim.yaml](./files/values-apim.yaml) file of this Advanced Feature. Please add this sample configuration to the existing **api** section of your **values-private.yaml** file in your [deploy/kyma/charts/sustainable-saas](../../../deploy/kyma/charts/sustainable-saas/) directory. The **api** section in your *values-private.yaml* file should look as follows: +3.1. Below you can see the required configuration for the API Management Integration. You can find a respective sample in the provided [*./files/values-apim.yaml*](./files/values-apim.yaml) file of this Advanced Feature. Please add this sample configuration to the existing **api** section of your **values-private.yaml** file in your [*/deploy/kyma/charts/sustainable-saas/*](../../../deploy/kyma/charts/sustainable-saas/) directory. The **api** section in your *values-private.yaml* file should look as follows: ```yaml ... @@ -100,7 +100,7 @@ helm upgrade susaas ./charts/sustainable-saas -f ./charts/sustainable-saas/value 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 **\-api-xsuaa-apim** Kyma Secret, which was created during the *helm upgrade*. Either get the Secret details via the Kyma Dashboard or using the following kubectl commands.
+> **Hint** - You can find the required details in your **\-api-xsuaa-apim** Kyma Secret, which was created during the *helm upgrade*. Either get the Secret details via the Kyma Dashboard or using the following kubectl commands.
> > ```kubectl get secret -api-xsuaa-apim -o jsonpath='{.data.clientid}' | base64 --decode```
> > ```kubectl get secret -api-xsuaa-apim -o jsonpath='{.data.clientsecret}' | base64 --decode```
> > ```kubectl get secret -api-xsuaa-apim -o jsonpath='{.data.url}' | base64 --decode```
@@ -240,9 +240,9 @@ As a smart and knowledgeable security enthusiast, you will probably wonder about - name: x-jwt-assertion ``` -- An Istio **Authorization Policy** ensures, that our API Service can only be reached by requests proving a dedicated Issuer and Subject claim as part of the **validated identity details**. In our sample scenario, we check the **requestPrincipals** property, which is following the structure - **\/\**. Keep in mind, if the JWT token in the **x-jwt-assertion** header is invalid or has not been issued by a trusted XSUAA tenant, this property will be empty and the request is blocked! +- An Istio **Authorization Policy** ensures, that our API Service can only be reached by requests proving a dedicated Issuer and Subject claim as part of the **validated identity details**. In our sample scenario, we check the **requestPrincipals** property, which is following the structure - **\/\**. Keep in mind, if the JWT token in the **x-jwt-assertion** header is invalid or has not been issued by a trusted XSUAA tenant, this property will be empty and the request is blocked! - > **Hint** - In case of XSUAA, the JWT issuer equals the **token endpoint** of the Provider Subaccount XSUAA Tenant (like https://sap-demo.authentication.us20.hana.ondemand.com/oauth/token) and the **Subject claim** contains the Client Id of the API XSUAA Service Instance. The default Subject structure follows **sb-\-api-\** and has to be provided in the *values.yaml* file (like **sb-susaas-api-default**). The asterisk is used on purpose in this case, as the Client Ids generated by XSUAA always contain a random character sequence after the exclamation mark! + > **Hint** - In case of XSUAA, the JWT issuer equals the **token endpoint** of the Provider Subaccount XSUAA Tenant (like https://sap-demo.authentication.us20.hana.ondemand.com/oauth/token) and the **Subject claim** contains the Client Id of the API XSUAA Service Instance. The default Subject structure follows **sb-\-api-\** and has to be provided in the *values.yaml* file (like **sb-susaas-api-default**). The asterisk is used on purpose in this case, as the Client Ids generated by XSUAA always contain a random character sequence after the exclamation mark! ```yaml apiVersion: security.istio.io/v1beta1 diff --git a/docu/4-expert/-CloudFoundry-/configure-transport-management/README.md b/docu/4-expert/-CloudFoundry-/configure-transport-management/README.md index ce72d2f..79ab9f3 100644 --- a/docu/4-expert/-CloudFoundry-/configure-transport-management/README.md +++ b/docu/4-expert/-CloudFoundry-/configure-transport-management/README.md @@ -1,7 +1,7 @@ # Setup SAP Cloud Transport Management -- ### **Kyma** ❌ -- ### **Cloud Foundry** ✅ +- **Kyma** ❌ +- **Cloud Foundry** ✅ > **Hint** - This Expert Feature requires refactoring and some screenshots and steps might be outdated. diff --git a/docu/4-expert/-CloudFoundry-/custom-domain-usage/README.md b/docu/4-expert/-CloudFoundry-/custom-domain-usage/README.md index 43c94c3..eef8f10 100644 --- a/docu/4-expert/-CloudFoundry-/custom-domain-usage/README.md +++ b/docu/4-expert/-CloudFoundry-/custom-domain-usage/README.md @@ -1,7 +1,7 @@ # Custom Domain Usage -- ### **Kyma** ❌ -- ### **Cloud Foundry** ✅ +- **Kyma** ❌ +- **Cloud Foundry** ✅ 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! @@ -23,7 +23,7 @@ In this part of the mission you will learn how to configure a custom domain for So, in this part of the **Expert Features**, 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 provided in the *files* directory ([click here](./files/free-basic-domain.mtaext)) of this **Expert Feature**. Search for the placeholder \ and replace it with your desired wildcard domain configured in the Custom Domain Service as you can see in the sample screenshot below. +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 provided in the *files* directory ([click here](./files/free-basic-domain.mtaext)) of this **Expert Feature**. Search for the placeholder \ and replace it with your desired wildcard domain configured in the Custom Domain Service as you can see in the sample screenshot below. [](./images/CDS_Mtaext.png?raw=true) @@ -229,12 +229,12 @@ The format of your consumer domains highly influences the number of required SSL | 3 wildcard certificates | 1 wildcard certificate | |---|---| -| \.susaas.com
\.test.susaas.com
\.dev.susaas.com | \.susaas.com
\-test.susaas.com
\-dev.susaas.com | +| \.susaas.com
\.test.susaas.com
\.dev.susaas.com | \.susaas.com
\-test.susaas.com
\-dev.susaas.com | | *.susaas.com
*.test.susaas.com
*.dev.susaas.com | *.susaas.com | | 3 wildcard certificates | 1 wildcard certificate
| |---|---| -| \.eu.susaas.com
\.us.susaas.com
\.ap.susaas.com | \-eu.susaas.com
\-us.susaas.com
\-ap.susaas.com | +| \.eu.susaas.com
\.us.susaas.com
\.ap.susaas.com | \-eu.susaas.com
\-us.susaas.com
\-ap.susaas.com | | *.eu.susaas.com
*.us.susaas.com
*.ap.susaas.com | *.susaas.com | Using subdomains instead of dashes to separate stages or regions will **easy the maintenance effort** from a provider perspective, but it will **increase the costs** of required wildcard SSL certificates. Let me give you one more sample. Let us assume you deployed your SaaS application to the eu10 and us20 region. Your sample consumers ABC and XYZ subscribe to the app in both regions. diff --git a/docu/4-expert/-CloudFoundry-/deploy-multiple-regions/README.md b/docu/4-expert/-CloudFoundry-/deploy-multiple-regions/README.md index 4b7b5e4..efd8664 100644 --- a/docu/4-expert/-CloudFoundry-/deploy-multiple-regions/README.md +++ b/docu/4-expert/-CloudFoundry-/deploy-multiple-regions/README.md @@ -1,7 +1,7 @@ # Deployment to multiple SAP BTP regions -- ### **Kyma** ❌ -- ### **Cloud Foundry** ✅ +- **Kyma** ❌ +- **Cloud Foundry** ✅ This part of the **Expert Features** will provide a high-level overview for SaaS providers planning to deploy their solution to multiple SAP BTP regions, including options for intelligent traffic routing. Offering your SaaS application in multiple SAP BTP regions has some great advantages which we will briefly discuss in the following chapter. diff --git a/docu/4-expert/-CloudFoundry-/multiple-hana-cloud/README.md b/docu/4-expert/-CloudFoundry-/multiple-hana-cloud/README.md index 491a7e9..16f7732 100644 --- a/docu/4-expert/-CloudFoundry-/multiple-hana-cloud/README.md +++ b/docu/4-expert/-CloudFoundry-/multiple-hana-cloud/README.md @@ -1,7 +1,7 @@ # Use multiple SAP HANA Cloud instances -- ### **Kyma** ❌ -- ### **Cloud Foundry** ✅ +- **Kyma** ❌ +- **Cloud Foundry** ✅ 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. 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 0913fc5..ac798d0 100644 --- a/docu/4-expert/-CloudFoundry-/setup-cicd-for-project/README.md +++ b/docu/4-expert/-CloudFoundry-/setup-cicd-for-project/README.md @@ -1,7 +1,7 @@ # Setup CI/CD for your Project -- ### **Kyma** ❌ -- ### **Cloud Foundry** ✅ +- **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. 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 4d6527a..66a70ec 100644 --- a/docu/4-expert/-CloudFoundry-/using-sap-theme-designer/README.md +++ b/docu/4-expert/-CloudFoundry-/using-sap-theme-designer/README.md @@ -1,7 +1,7 @@ # Using SAP Theme Designer with multitenancy -- ### **Kyma** ❌ -- ### **Cloud Foundry** ✅ +- **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. diff --git a/docu/4-expert/-Kyma-/custom-domain-usage/README.md b/docu/4-expert/-Kyma-/custom-domain-usage/README.md index 10efdd5..0209109 100644 --- a/docu/4-expert/-Kyma-/custom-domain-usage/README.md +++ b/docu/4-expert/-Kyma-/custom-domain-usage/README.md @@ -1,7 +1,7 @@ # Custom Domain in SAP BTP Kyma Runtime -- ### **Kyma** ✅ -- ### **Cloud Foundry** ❌ +- **Kyma** ✅ +- **Cloud Foundry** ❌ In this part of the tutorial, you will learn how to set up a Custom Domain in your Kyma Cluster using AWS Route 53. @@ -408,7 +408,7 @@ On your root directory, run the command below: helm upgrade susaas deploy/kyma/charts/sustainable-saas -f deploy/kyma/charts/sustainable-saas/values-private.yaml -n default ``` -Now you can go ahead and [subscribe](../../../2-basic/4-subscribe-consumer-subaccount/), you should see that your application is using your new domain. +Now you can go ahead and [subscribe](../../../2-basic/4-subscribe-consumer-subaccount/README.md), you should see that your application is using your new domain. > Hint: If you have already existing tenants and you want to update their URL's with the new ones using which includes your custom domain, you should go to the Subscription Management Dashboard > and update your tenants. Please check this [official documentation](https://help.sap.com/docs/btp/sap-business-technology-platform/using-subscription-management-dashboard) for guidance. diff --git a/docu/4-expert/-Kyma-/saas-self-onboarding/README.md b/docu/4-expert/-Kyma-/saas-self-onboarding/README.md index 5cba6be..800f5fb 100644 --- a/docu/4-expert/-Kyma-/saas-self-onboarding/README.md +++ b/docu/4-expert/-Kyma-/saas-self-onboarding/README.md @@ -1,7 +1,7 @@ # Self-Registration, Onboarding Automation and One-Domain Concept -- ### **Kyma** ✅ -- ### **Cloud Foundry** ❌ +- **Kyma** ✅ +- **Cloud Foundry** ❌ In this part of the tutorial, you will learn how to set up self-registration, automated tenant onboarding, and an exemplary single-domain concept for your SaaS application. @@ -70,7 +70,7 @@ To implement the self-registration, onboarding automation, and one-domain concep > **Hint** - The Onboarding Process cannot be handled by the existing workloads of your Sustainable SaaS application, as for instead of SAP XSUAA, the SAP Identity Authentication Service is being used for authenticating users. A parallel binding of SAP XSUAA and SAP IAS is not supported. -2.1. Switch to the [*./files/deploy*](./files/deploy/) directory of this Expert Feature, containing all objects required to setup this expert scenario. +2.1. Switch to the [*./files/deploy/*](./files/deploy/) directory of this Expert Feature, containing all objects required to setup this expert scenario. 2.2. Ensure you are connected to your container image repository. @@ -261,17 +261,17 @@ Alright, so you have almost finished all preparation steps to install the requir **router** - * image.repository - Provide the details of your **Onboarding Application Router** Container Image like \/obd-router if your Image is stored in Docker Hub or ghcr.io/\/obd-router in case of GitHub. + * image.repository - Provide the details of your **Onboarding Application Router** Container Image like \/obd-router if your Image is stored in Docker Hub or ghcr.io/\/obd-router in case of GitHub. * image.tag - Provide a different tag, if you do not want to use the latest image. **srv** - * image.repository - Provide the details of your **Onboarding CAP Backend Service** Docker Image repository like \/obd-srv. + * image.repository - Provide the details of your **Onboarding CAP Backend Service** Docker Image repository like \/obd-srv. * image.tag - Provide a different tag, if you do not want to use the latest image. **html5_apps_deployer** - * image.repository - Provide the details of your **Onboarding HTML5 Apps Deployer** Docker Image repository like \/obd-html5-deployer. + * image.repository - Provide the details of your **Onboarding HTML5 Apps Deployer** Docker Image repository like \/obd-html5-deployer. * image.tag - Provide a different tag, if you do not want to use the latest image. @@ -320,7 +320,7 @@ helm template ./charts -f ./charts/values-private.yaml > helm-template.yaml 5.1. Please run the following command from within the *./docu/4-expert/-Kyma-/saas-self-onboarding/files/deploy* directory to deploy the Onboarding application to the **same namespace** in which your target SaaS application resides! -> **Important** - The \ placeholder has to be replaced with the Release name of the original Saas Application to be onboarded. +> **Important** - The \ placeholder has to be replaced with the Release name of the original Saas Application to be onboarded. > **Hint** - Feel free to add the *--debug* parameter to get some more verbose output if you're interested what's happening under the hood! @@ -381,7 +381,7 @@ Once the Onboarding components have been successfully deployed, the next step is 6.1. Open the Administration UI of your SAP Identity Authentication Service tenant. -> **Hint** - Usually you can reach the Administration UI of your tenant following the **https://\.accounts.ondemand.com/admin** pattern. +> **Hint** - Usually you can reach the Administration UI of your tenant following the **https://\.accounts.ondemand.com/admin** pattern. > > Example - https://sap-demo.accounts.ondemand.com/admin @@ -408,9 +408,9 @@ You are now ready to test your setup, by self-registering a new user in SAP Iden 7.1. Open the SaaS application Home Screen in a new browser session or Incognito Mode. -> **Hint** - You will be able to access it following the **https://\-\.\** format
+> **Hint** - You will be able to access it following the **https://\-\.\** format
> - *https://susaas-default.a1b2c3.kyma.ondemand.com* or *https://susaas-default.sap-demo.com* (when using a custom domain)
-> - You can find the respective URI also as part of your new Virtual Service artifact in your Kyma Dashboard (\-\)
+> - You can find the respective URI also as part of your new Virtual Service artifact in your Kyma Dashboard (\-\)
> [](./images/OBD_VirtualService.png?raw=true) 7.2. Follow the steps explained in our recent blog post, to register a new user in SAP Identity Authentication Service and to onboard a new subscriber tenant. @@ -426,7 +426,7 @@ To clean-up the scenario and to remove the Self-Registration and One-Domain feat 8.1. Undeploy the **Helm Release** from your Kyma Cluster. -> **Hint** - The \ placeholder contains the Helm Release Name of your original Sustainable SaaS application deployment. +> **Hint** - The \ placeholder contains the Helm Release Name of your original Sustainable SaaS application deployment. ```sh # Run from anywhere # diff --git a/docu/4-expert/-Kyma-/setup-cicd-for-project/README.md b/docu/4-expert/-Kyma-/setup-cicd-for-project/README.md index 118a577..6a7132a 100644 --- a/docu/4-expert/-Kyma-/setup-cicd-for-project/README.md +++ b/docu/4-expert/-Kyma-/setup-cicd-for-project/README.md @@ -1,7 +1,7 @@ # Setup CI/CD for your Project -- ### **Kyma** ✅ -- ### **Cloud Foundry** ❌ +- **Kyma** ✅ +- **Cloud Foundry** ❌ In this part of the **Expert Features** is work-in-progress. Please check again at a later point of time or be adventurous and explore the provided files. diff --git a/docu/4-expert/0-introduction-expert-features/README.md b/docu/4-expert/0-introduction-expert-features/README.md index 3ca1553..7df64d1 100644 --- a/docu/4-expert/0-introduction-expert-features/README.md +++ b/docu/4-expert/0-introduction-expert-features/README.md @@ -1,7 +1,7 @@ # Introduction to the Expert Features -- ### **Kyma** ✅ -- ### **Cloud Foundry** ✅ +- **Kyma** ✅ +- **Cloud Foundry** ✅ > **Important** - The **Expert Features** contain selected additional components that can be applied to the Basic **or** the Advanced Version of the SaaS application. Most chapters of the **Expert Features** are still being actively worked on! Feel free to browse the available sections to get an idea of what to expect once published. Some of the chapters already contain useful content while others will be uploaded during the next weeks and months. diff --git a/docu/4-expert/backup-database-containers/README.md b/docu/4-expert/backup-database-containers/README.md index e557cbf..f59dd7e 100644 --- a/docu/4-expert/backup-database-containers/README.md +++ b/docu/4-expert/backup-database-containers/README.md @@ -1,7 +1,7 @@ # Backup SAP HANA Cloud Database Containers -- ### **Kyma** ✅ -- ### **Cloud Foundry** ✅ +- **Kyma** ✅ +- **Cloud Foundry** ✅ > **Hint** - This Expert Feature requires refactoring and some screenshots and steps might be outdated. diff --git a/docu/4-expert/consumer-extensibility/README.md b/docu/4-expert/consumer-extensibility/README.md index cb073d7..5806f12 100644 --- a/docu/4-expert/consumer-extensibility/README.md +++ b/docu/4-expert/consumer-extensibility/README.md @@ -1,7 +1,7 @@ # SaaS Consumer Extensibility -- ### **Kyma** ✅ -- ### **Cloud Foundry** ✅ +- **Kyma** ✅ +- **Cloud Foundry** ✅ In this part of the mission you will learn how SaaS consumers can extend their SaaS subscriptions with their own **data model extensions** and **user interface extensions** using dedicated **CAP extensibility** features. @@ -183,7 +183,7 @@ cds login cf-susaas-provider-ef3f1f64.cfapps.us10.hana.ondemand.com -s susaas-su 4.9. You can generate that passcode by opening the following URL in your browser and logging in with your credentials. -https://\.authentication.\.hana.ondemand.com/passcode +https://\.authentication.\.hana.ondemand.com/passcode **Example** diff --git a/docu/4-expert/custom-domain-for-ias/README.md b/docu/4-expert/custom-domain-for-ias/README.md index 646dbe5..2fe1cca 100644 --- a/docu/4-expert/custom-domain-for-ias/README.md +++ b/docu/4-expert/custom-domain-for-ias/README.md @@ -1,7 +1,7 @@ # Custom Domain for SAP Identity Authentication -- ### **Kyma** ✅ -- ### **Cloud Foundry** ✅ +- **Kyma** ✅ +- **Cloud Foundry** ✅ In this part of the Expert Features you will learn how to configure a custom domain for your SAP Identity Authentication instance. As the official SAP Help documentation ([click here](https://help.sap.com/docs/IDENTITY_AUTHENTICATION/6d6d63354d1242d185ab4830fc04feb1/c4db840ff2464e12ab68d94efb0769c3.html?locale=en-US)) on this requirement is already quite extensive, we will use this tutorial to show you a sample setup and give you some tips and tricks. diff --git a/docu/4-expert/feature-toggles/README.md b/docu/4-expert/feature-toggles/README.md index 59766b8..08d0a93 100644 --- a/docu/4-expert/feature-toggles/README.md +++ b/docu/4-expert/feature-toggles/README.md @@ -1,7 +1,7 @@ # Feature Toggles -- ### **Kyma** ✅ -- ### **Cloud Foundry** ✅ +- **Kyma** ✅ +- **Cloud Foundry** ✅ In this part of the mission, you will learn how SaaS providers can enable features for dedicated SaaS consumer tenants or even single users using so-called **Feature Toggles**. diff --git a/docu/4-expert/hdi-container-administration/README.md b/docu/4-expert/hdi-container-administration/README.md index fc686c3..5fa50bf 100644 --- a/docu/4-expert/hdi-container-administration/README.md +++ b/docu/4-expert/hdi-container-administration/README.md @@ -1,7 +1,7 @@ # HDI Container Administration -- ### **Kyma** ✅ -- ### **Cloud Foundry** ✅ +- **Kyma** ✅ +- **Cloud Foundry** ✅ > **Hint** - This Expert Feature requires refactoring and some screenshots and steps might be outdated. diff --git a/docu/4-expert/integrate-consumers-idp/README.md b/docu/4-expert/integrate-consumers-idp/README.md index 34f9c2d..16f5b37 100644 --- a/docu/4-expert/integrate-consumers-idp/README.md +++ b/docu/4-expert/integrate-consumers-idp/README.md @@ -1,7 +1,7 @@ # Integration of Consumer IdPs -- ### **Kyma** ✅ -- ### **Cloud Foundry** ✅ +- **Kyma** ✅ +- **Cloud Foundry** ✅ In this part of the **Expert Features** you will learn how to integrate Consumer IdPs (Identity Providers) like Azure Active Directory. As we did not explicitly set up a dedicated Consumer IdP in our SaaS sample scenario, in this chapter we will just briefly highlight some possible approaches. diff --git a/docu/4-expert/local-hybrid-development/README.md b/docu/4-expert/local-hybrid-development/README.md index 8e9b841..3c403b2 100644 --- a/docu/4-expert/local-hybrid-development/README.md +++ b/docu/4-expert/local-hybrid-development/README.md @@ -1,7 +1,7 @@ # Local and hybrid development -- ### **Kyma** ✅ -- ### **Cloud Foundry** ✅ +- **Kyma** ✅ +- **Cloud Foundry** ✅ In this part of the **Expert Features** you will learn how to use the local and hybrid development features of CAP. This will simplify the development process and let's you implement new features in a local environment with and without multitenancy enable. @@ -356,7 +356,7 @@ Make sure to target the correct Cloud Foundry Organization and Space. For hybrid testing in a Kyma scenario, you need to store valid Service Binding details in the *srv/.cdsrc-private.json* file. To do so, please run the following commands from the *code* directory. -> **Important** - Please replace the **\** placeholder with the Kyma Release Name of your Deployment (e.g., susaas or susaas-prod). +> **Important** - Please replace the **\** placeholder with the Kyma Release Name of your Deployment (e.g., susaas or susaas-prod). ```sh cds bind -2 -srv-destination,-srv-xsuaa --on k8s --for hybrid --output-file srv/.cdsrc-private.json @@ -388,7 +388,7 @@ cf csk -susaas-service-manager-admin -susaas-service-manag Once all Service Keys have been created successfully, please add them to your hybrid testing profile, stored in *srv/.cdsrc-private.json*. To do so, please run the following commands from the *code* directory. -> **Important** - Please replace the **\** placeholder with your Cloud Foundry Space name. +> **Important** - Please replace the **\** placeholder with your Cloud Foundry Space name. ```sh cds bind -2 -susaas-destination,-susaas-uaa --for hybrid --output-file srv/.cdsrc-private.json @@ -428,7 +428,7 @@ In this section you will be running your frontend application with the connectio For hybrid testing in a Kyma scenario, you need to store valid Service Binding details in the *router/.cdsrc-private.json* file. To do so, please run the following commands from the *code* directory. -> **Important** - Please replace the **\** placeholder with the Kyma Release Name of your Deployment (e.g., susaas or susaas-prod). +> **Important** - Please replace the **\** placeholder with the Kyma Release Name of your Deployment (e.g., susaas or susaas-prod). ```sh cds bind -2 -router-destination,-router-xsuaa --on k8s --for hybrid --output-file router/.cdsrc-private.json @@ -443,7 +443,7 @@ This is it, you are ready to proceed with the next steps and start your router i Run the following commands in your *code* directory to create Service Keys in Cloud Foundry, which can be used for hybrid testing. -> **Important** - Please replace the **\** placeholder with your Cloud Foundry Space Name. +> **Important** - Please replace the **\** placeholder with your Cloud Foundry Space Name. ```sh cf csk -susaas-uaa -susaas-uaa-key @@ -453,7 +453,7 @@ cf csk -susaas-html5-repo-runtime -susaas-html5-repo-runti Once all Service Keys have been created successfully, please add them to your hybrid testing profile, stored in *router/.cdsrc-private.json*. To do so, please run the following commands from the *code* directory. -> **Important** - Please replace the **\** placeholder with your Cloud Foundry Space name. +> **Important** - Please replace the **\** placeholder with your Cloud Foundry Space name. ```sh cds bind -2 -susaas-destination,-susaas-uaa --for hybrid --output-file router/.cdsrc-private.json cds bind html5-apps-repo -2 -susaas-html5-repo-runtime --kind html5-apps-repo --for hybrid --output-file router/.cdsrc-private.json @@ -498,7 +498,7 @@ Before running the SaaS API in hybrid mode, please make sure to terminate your l For hybrid testing in a Kyma scenario, you need to store valid Service Binding details in the *api/.cdsrc-private.json* file. To do so, please run the following commands from the *code* directory. -> **Important** - Please replace the **\** placeholder with the Kyma Release Name of your Deployment (e.g., susaas or susaas-prod). +> **Important** - Please replace the **\** placeholder with the Kyma Release Name of your Deployment (e.g., susaas or susaas-prod). ```sh cds bind -2 -api-xsuaa-api --on k8s --for hybrid --output-file api/.cdsrc-private.json @@ -513,7 +513,7 @@ This is it, you are ready to proceed with the next steps and start your API in h Run the following commands in your *code* directory to create Service Keys in Cloud Foundry, which can be used for hybrid testing. -> **Important** - Please replace the **\** placeholder with your Cloud Foundry Space Name. +> **Important** - Please replace the **\** placeholder with your Cloud Foundry Space Name. ```sh cf csk -susaas-api-uaa -susaas-api-uaa-key @@ -522,7 +522,7 @@ cf csk -susaas-service-manager -susaas-service-manager-key Once all Service Keys have been created successfully, please add them to your hybrid testing profile, stored in *api/.cdsrc-private.json*. To do so, please run the following commands from the *code* directory. -> **Important** - Please replace the **\** placeholder with your Cloud Foundry Space name. +> **Important** - Please replace the **\** placeholder with your Cloud Foundry Space name. ```sh cds bind -2 -susaas-api-uaa --for hybrid --output-file api/.cdsrc-private.json cds bind sm-container -2 -susaas-service-manager --kind service-manager --for hybrid --output-file api/.cdsrc-private.json diff --git a/docu/4-expert/manage-tenant-containers/README.md b/docu/4-expert/manage-tenant-containers/README.md index 3cf54e1..25b7c00 100644 --- a/docu/4-expert/manage-tenant-containers/README.md +++ b/docu/4-expert/manage-tenant-containers/README.md @@ -1,7 +1,7 @@ # Manage Tenant Database Containers -- ### **Kyma** ✅ -- ### **Cloud Foundry** ✅ +- **Kyma** ✅ +- **Cloud Foundry** ✅ In this part of the **Expert Features** you will learn how to access and manage tenant database containers. In this sample scenario, you will be accessing a respective tenant database container with a user that is assigned administrative permissions for the underlying database schema like **CREATE ANY, SELECT, EXECUTE, or DROP** SQL permissions. diff --git a/docu/4-expert/send-emails-graph-api/README.md b/docu/4-expert/send-emails-graph-api/README.md index eaae4e6..1c26a0f 100644 --- a/docu/4-expert/send-emails-graph-api/README.md +++ b/docu/4-expert/send-emails-graph-api/README.md @@ -1,7 +1,7 @@ # Send e-mails using Microsoft Graph -- ### **Kyma** ✅ -- ### **Cloud Foundry** ✅ +- **Kyma** ✅ +- **Cloud Foundry** ✅ In this tutorial, you will learn how to send e-mails from your SaaS application using the Microsoft Graph API and Exchange Online. This can be useful in scenarios requiring automated messages sent to users from within your application. This is just one approach how to programmatically send e-mails using popular Microsoft services. Alternatively, you might think about configuring a destination to your SMTP server or using similar services offered by other providers like AWS Simple Email Service (SES) or SendGrid. @@ -123,7 +123,7 @@ You can use a standard Azure Active Directory **Application Registration** to se ## 5. Test the sample application -5.1. Go to the [code directory](../send-emails-graph-api/code/) of this Expert Feature topic where you can find the sample application for testing your setup. Copy the index.js and package.json files to place on your local device - just to ensure you're not pushing any of your secrets to GitHub. +5.1. Go to the [*./code*](./code/) of this Expert Feature topic where you can find the sample application for testing your setup. Copy the index.js and package.json files to place on your local device - just to ensure you're not pushing any of your secrets to GitHub. 5.2. Open a terminal window and switch to the directory in which you copied the provided files. Install the required dependencies by running the **npm install** command in the respective directory. diff --git a/docu/4-expert/update-tenant-containers/README.md b/docu/4-expert/update-tenant-containers/README.md index 06105e1..50ce712 100644 --- a/docu/4-expert/update-tenant-containers/README.md +++ b/docu/4-expert/update-tenant-containers/README.md @@ -1,7 +1,7 @@ # Update tenant database containers -- ### **Kyma** ✅ -- ### **Cloud Foundry** ✅ +- **Kyma** ✅ +- **Cloud Foundry** ✅ In this part of the **Expert Features**, you will learn how to distribute data model changes to your tenant database containers using API calls.