- 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.
Hint - This chapter will not cover the files in the deploy folder, which will be explained in further detail within the respective environment-specific subfolders.
Also, check out our Explore the components chapter (click here), which describes the various SaaS application components and their tasks in greater detail (click here). For now, let us start with a brief overview, before deep-diving into the different sub-directories.
The code directory of our GitHub repository consists of several sub-directories containing the API (Service) Broker, the API Service, and the different application layers like User Interface, the Backend Business Application service layer, and the data models deployed in a tenant-specific and shared database container. Furthermore, you can find the Helm Charts (required for the Kyma deployment), content supporting local testing or even examples how to extend the SaaS application.
 |
api - CAP-based API Service app - SAP Fiori Elements UIs and App Deployer broker - API Service Broker db - Tenant data model db-com - Shared data model router - Application Router srv - CAP-based SaaS Service test - Unit tests, API tests and sample data .env.sample - Environment variables for local testing package.json - CDS build configs and dependencies for local testing |
The api directory contains the implementation of the CAP-based API Service which can be used by SaaS consumers to upload or maintain data in their Tenant database containers. Further details can be found in a separate part of this tutorial (click here).
Hint - Using Kyma, the API Service container image is build using Cloud Native Buildpacks, therefore the directory does not contain a separate Dockerfile. Further details on the build process are provided in a separate part of the tutorial (click here)!
 |
srv - CAP application folder .cdsrc.json - CDS profile for productive usage |
Besides the html5-deployer directory (containing the HTML5 Application Deployer - find details here), the app directory contains all SAP Fiori Elements modules, which result in dynamically generated UIs, based on the OData Backend Service annotations. During the UI build process, all four UI modules are zipped and copied into a resources folder within the html5-deployer directory. This folder is created during the very first build.
Hint - In Cloud Foundry, the HTML5 Apps Deployer is not required during productive deployment but can still be used for deployments from your local development environment.
Hint - Using Kyma, the HTML5 Apps Deployer container image is build using an existing Docker Image maintained by SAP, which is referenced in the respective Dockerfile. Further details on the build process are provided in a separate part of the tutorial (click here).
 |
html5-deployer - HTML5 Application Deployer .dockerignore - Ignores package.json for docker build webapp - UI5 applicaton resources ext - Fiori Elements extensions package.json - Required for build process ui-public-assessments - UI for assessment management ui-public-flp - UI for sandbox launchpad ui-public-projects - UI for viewing project details launchpad.html - Sandbox launchpad |
The ui-public-flp UI module contains a Sandbox Launchpad. The Application Router welcomeFile property is routing to this module stored in the HTML5 Application Repository.
The broker directory contains the API Service Broker implementation. In the Kyma-based scenario, the catalog.json file content (which is required to define service plans provided by the Service Broker) is part of the Helm Charts (click here), as the required details are only available upon deployment to your Kyma Cluster.
Hint - Using Kyma, the API Service Broker container image is build using Cloud Native Buildpacks, therefore the directory does not contain a separate Dockerfile. Further details on the build process are provided in another part of the tutorial!
 |
catalog.json - Contains the provided service plan details package.json - Node.js dependencies and start script start.js - Custom start script for API Service Broker (reading credentials from env variables) |
The db directory contains the definition of our Tenant data model, which is deployed to a separate isolated SAP HANA Cloud HDI (HANA Deployment Infrastructure) database containers for each and every SaaS Tenant upon subscription. Besides a CDS-based data model, the directory also contains SAP HANA native objects (e.g., hdbgrants or synonyms) for accessing the shared HDI database container. You can learn more about this in the Explore the Components chapter (click here).
Important - Make sure to run a cds build --production in case of changes to the Tenant data model before starting a deployment to Cloud Foundry or building new Docker Images of your SaaS Backend Service.
Hint - As the Tenant data model is part of our SaaS Backend Service and deployed to new Tenant database containers at runtime, there is no need to build a separate Deployment Docker Image for this component. The data model definition is stored as a .tgz file within the Backend Service and the mtxs Deployment Service (click here) allows an automated deployment to new database containers.
Important - Based on the CDS profiles used in cds watch or cds build, the Tenant data model includes or excludes sample data. For local testing using sqlite, application (e.g., Products) and master data tables (e.g., Currencies or Countries) and sample values are part of the Tenant data model. For production builds targeting SAP HANA Cloud, the application data sample values are excluded to prevent overwriting existing content.
 |
cfg - Configuration for shared data model access hana - Data model extension for production build (adds reference to shared database table) sqlite - Data model extension for local testing (mocks shared database table locally) csv - Sample data for mocked shared table src - Native SAP HANA database objects functions - Sample SAP HANA function data-types.cds - CAP data model types undeploy.json - Undeploy configuration |
The db-com directory contains the definition of a shared data model, which is accessible from all isolated Tenant database containers. It is used for data required and shared by all Consumer Tenants. The shared data model has to be deployed separately into a dedicated SAP HANA Cloud HDI database container during deployment of the SaaS sample application.
Hint - Using Kyma, the container image deploying the shared data model to a dedicated database container, is build using Cloud Native Buildpacks, therefore the directory does not contain a separate Dockerfile. Further details on the build process are provided in a separate part of the tutorial (click here)!
 |
csv - Sample content for shared data model src - Native SAP HANA database objects *_ACCESS.hdbrole - Roles for access from Tenant containers data-model.cds - Shared CAP data modelundeploy.json - Undeploy configuration |
The router directory contains all files of the Application Router required by our SaaS sample application. In this case, only the xs-app.json file and a health-check is required.
Hint - The Application Router Docker Image build process makes use of the official sapse/approuter Docker Image. Further details on the build process are provided in a separate part of the tutorial (click here)!
 |
.dockerignore - Ignore package.json for docker build Dockerfile - Docker image based on sapse/approuter for Kyma deployment index.js - Custom index.js for health checks and cookie purposes package.json - Required for local testing and Cloud Foundry deployment xs-app.json - Route definitions for productive usage |
The annotations folder in the srv directory contains all service annotations required to generate the Fiori Elements UIs of our sample application. These annotations define the capabilities of the OData Services but also set the layouts of the SAP Fiori Elements user interfaces.
Hint - As for any other changes to the SaaS Backend Service, make sure to run a cds build --production in case of any changes to the annotation files before building a new Docker Image!
 |
admin - Admin Service annotations public - User Service annotations capabilities.cds - Service capability annotations valueHelp.cds - Value help annotations |
Hint - Yes, these annotation files can also be part of your UI modules as you can see in other tutorials. Feel free to move them around if you feel more comfortable storing the annotations among your actual UI components.
The rest of the srv directory contains the implementation of our Business Application or central SaaS Backend Service. This includes OData-Services (admin-service.js/cds and user-service.js/cds) for our Fiori Elements UIs, as well as the automation logic executed on the subscription of new consumer-tenants (provisioning.js). The corresponding subscription service endpoints are exposed by using the CAP mtxs (click here for further details).
Onboarding Automation
A lot of the Tenant onboarding steps have been automated using platform APIs and SAP BTP services. Start from the provisioning.js file and deep-dive into the various utilities like e.g., kyma-utils.js, creating API Rules for new subscribers by interacting with the Kyma API Server.
The Onboarding Automation is the only part of the code-line, which contains runtime specific code for both, the SAP BTP, Kyma and Cloud Foundry Runtime. Those can be found in the utils/kyma-utils.js and cf-utils.js helper files as well as in some of the other modules returning runtime-specific class instances like the following sample.
utils/automator
export default (process.env.VCAP_APPLICATION ? CloudFoundry : Kyma)Hint - The SaaS Backend Service Docker Image is build using Cloud Native Buildpacks, therefore the directory does not contain a separate Dockerfile. Further details on the build process are provided in a separate part of the tutorial (click here)!
 |
srv - CAP application folder annotations - Covered in separate chapter alertNotification.js - Alert Notification utilities .cdsrc.json - CDS profile for productive usage |
The test directory contains sample data for local development and testing purposes as well as sample unit tests.
Hint - These files should not be part of a productive deployment and are not part of the production build profile.
|
data - Sample data for tenant data model (sample data used for local testing) http - Sample HTTP requests for testing api* - HTTP requests for API testing index.cds - CDS file for reference test.js - Sample unit tests |