Objectives
This lesson explains how to set up and manage the SAP BTP account model, including global accounts, subaccounts, and environments. It describes SAP BTP's architecture and how to set up your account structures in a useful and reliable way.
This lesson contains the following topics:
The SAP BTP account model comprises global accounts, directories, subaccounts, and environments. It's used to organize resources, manage access rights, and structure billing information.
The accounts in SAP Business Technology Platform are divided into global accounts, directories, and subaccounts.
A global account represents your signed contract with SAP. It's used to manage subaccounts that are organized in directories. The billing of this contract is based on the entitlements that you have purchased (that is, SAP HANA Cloud, SAP Build Code). These entitlements are distributed as assignments to subaccounts through directories with a quota for actual consumption.
Subaccounts are independent of each other and run in a specific region. The available regions for subaccounts are defined in the global account. A region is the physical location where applications, data, or services are hosted. The region assigned to a subaccount does not have to be directly connected to the user's location.
Global accounts, directories, and subaccounts are managed in the SAP BTP Cockpit. The cockpit is the central tool for operations including administration and development.
Depending on your geographical location, you can choose one of the following gateways to improve the performance of the SAP BTP cockpit. These gateways only determine how you access the cockpit. They do not restrict access to subaccounts running in other regions in any way:
The purpose of directories is to organize subaccounts. This can be based on categories such as regions or departments, services or solutions, technical aspects, or business topics.
A directory only needs a name, a description, and a superordinate object such as the global account or another directory. The highest level of a given path is always the global account, the lowest level is a subaccount, which means that you can have up to five directory levels.
A subaccount requires the same information as a directory and also has global account or a directory as its parent object. In addition, subaccounts also require a region and a unique subdomain. The subdomain becomes part of the URL for accessing applications in the subaccount.
A lot of capabilities from SAP BTP are delivered as services. Some of the services are always for free, while other ones need to get paid for additionally. Before you can utilize a service, you need to subscribe to it or create an instance of your selected service. Before doing that, you need to be familiar with the service plans which are available for this service to select the right one for your scenario. You can get more information about the existing service plans of a service in the SAP Discovery Center or the documentation on the SAP Help Portal. We can differentiate between two types of services: There are lots of services available and you can use them for several use cases. Services can be instantiated or subscribed.
In the figure, Example Use of Services on SAP BTP, you see a potential use case for some services.
Your developers have the task to develop a SAPUI5 application with SAP Cloud Application Programming Model. This application should be hosted on the SAP BTP.
The developers decide to use the SAP Business Application Studio as the IDE. For the Continuous Integration and Delivery pipeline, they use the Continuous Integration & Delivery service of SAP BTP. The application gets deployed inside the Cloud Foundry Environment of the SAP BTP. The developers use the SAP HANA Cloud to store data of the application (database as a service).
While you want the operation and productive use of the application to ensure security through authorization management, you want to write logs and handle load automatically.
For the authorization, your developers use the Authorization and Trust Management service. For the logs, they can connect the application to the Application Logging Service. For handling loads dynamically, your developers can create an instance of the Application Autoscaler, configure it with scaling rules, and bind it to the application.
In addition to the use case from this scenario, there are more potential use cases and even more services that could be used.
The Shared Responsibility Model between your company and SAP defines how responsibilities are divided. SAP manages the platform, whereas your company develops and manages applications and the corresponding data. SAP is responsible for the infrastructure, including the physical security of data centers, network controls, and operational security including monitoring. Based on this, SAP is responsible for:
Customers are responsible for their data, access management, and applications and their security. This model ensures that both parties contribute to maintaining a secure environment, with SAP handling the underlying platform, in this case SAP BTP, and users managing their specific configurations.
Product Documentation: Shared Responsibility Model Between You and SAP
Setting up the account model includes the creation of global accounts, directories and subaccounts, the assignment of entitlements and authorizations and the configuration of environments and services. This enables structured and secure management of platform resources.
There are various ways to structure your accounts. The following are common examples.
In this example, the directories are structured by division (Finance, Sales, Shared resources) and then the development stage in these division are structured underneath. Of course, you could also use other criteria such as enterprise domains or similar.
Next to this, labels are used to add meta data information to the structures. This meta data is additional information like a cost center for better cost management, owner contact details, or whatever you need, as labels are free text key-value pairs.
It's strongly recommended to separate your development scenarios and projects to allow easier configurations and project execution.
This allows you to set up different trust configurations between subaccounts, for example, one Identity Provider for testing scenarios and the productive one for your prod subaccount.
You can better restrict access to apps and their administration. With this, you can ensure higher security, if not every SAP BTP Cockpit user is authorized to work in productively used subaccount.
You create a dedicated development subaccount per project – developed apps get consolidated, tested and published in one single testing and one productive subaccount.
This approach is especially well suited for companies with focus on continuous integration and continuous delivery (CI/CD), as it lets every development project decide separately about their development project.
If needed, additional testing and/or productive subaccounts could also be created.
Creating separate development, testing, and productive subaccounts for each division. This allows you to completely distribute the development, administration, and operations to several teams. This is very helpful in large scenarios where multiple projects are running in multiple divisions of a company. It's recommended to make use of directories and labels to better structure the accounts and review costs on a finer level.
If you want to learn more about the account setups or other helpful SAP BTP information, check out the SAP BTP Administrator's Guide
Log in to track your progress & complete quizzes