Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
Showing results for 
Search instead for 
Did you mean: 
Many SAP customers initially subscribe to SAP BTP for one or two services that they need for the projects in scope. As the discovery and design phases unveil, and also as more BTP services are rolled out onto the platform, customers may find out that more BTP services can be leveraged in their project implementations. This blog post illustrates some common criterions involved in assessing the applicability of a BTP service for customer’s adoptions.


Where to find the service that I need

While the SAP BTP introduction site ( gives an overview of SAP BTP and its benefits to businesses, the site is too general for people who are looking for a BTP service that can help them to solve a technical or business problem. I found that the SAP Discovery Center ( is very helpful. On this site, you can search services in various ways and the returned results are normally very relevant.


Once the service is found, pay attention to the tag at the top of the card.

Services Found

If it indicates “RETIRING SOON”, it should not be positioned as part of your solution.

Service details can be found by clicking on the service card. On the overview page, the service document can be found on the Resources section:

Link to Service Document


Functionality Match

Yes of course. The service has to have the features needed. In cases where integration to the service is required, the service has to have APIs or events for external systems to connect to.

All these details can be found in the service document mentioned in the previous section.


On Premises, Self-Managed vs. SaaS

Sometimes, a company has the option of installing a freeware or a cheaper solution that also fits its need and manage it by self. While this the short-term approach may reduce project cost temporarily, more companies are inclined to use the SaaS services in BTP. Security, maintenance, availability and scalability are all concerns with self-managed services and addressing which may end up with higher costs than using BTP services.


Regional Availability

Although an SAP BTP is available in multiple regions across the world, not all BTP services are available in all country’s regions. Due to each country’s legislations and the company’s contracts with its business partners, some may require that the BTP service be in the region that is inside the country. For example, some requires that any data that contains personal information must be stored and even processed within the country.

Thus when looking at the service at the Discovery Center afore mentioned, pay attention to the regional availabilities on the Pricing tab:

Service Available Regions

Regional Availability also affects your landscape creation and/or even your design. The service must be under a subaccount in its available region.  As very few things can be shared across subaccounts, if two services are needed and there happens to be no region that has both of these two services, then two subaccounts are to be created, and resource sharing or communication between the two subaccounts are to be considered.



This is where SaaS is superior to on premise. For all the services in SAP BTP, their performances do not vary by environment type. Typically we create different subaccounts for different types of environments, Development, QA or Production environments are just different subaccounts and the services perform the same under these different subaccounts.  Based on our experience, the services performances are typically steady with reasonable concurrencies. Well, that’s the nature of SaaS isn’t it.



Security assessment is always part of the analysis when selecting a service to use. In this respect, SAP With SAP BTP services have the following characteristics:

  • For the Featured services, users need to have access to the subaccount and granted the proper Role Collections

  • All services are accessed via HTTPS TLS 1.2

  • All APIs provided by the services are guarded by OAuth 2.0 at least

  • All data persisted by the services are encrypted (Encryption at Rest)

  • All services are guarded by the hyperscaler’s infrastructure’s security layer. For example, on AWS, services are guarded by AWS Shield.

  • SAP Cloud Connector can be used to secure integration between SAP BTP services and applications or services outside of SAP BTP

Other aspects of the security compliances of the BTP services can be found at the SAP Trust Center:

A service's security is a shared responsibility among service user, SAP and the selected hyperscaler (AWS, AZure, GCP or Alibaba). Here is a very helpful blog post:


High Availability and Disaster Recovery

As SAP BTP is made available across multiple data centers around the globe, and the data centers are grouped into “Regions”. That means, each Region is consisted of multiple data centers. SAP BTP services support the Multiple Availability Zones (AZ) for regional high availability. An Availability zone (AZ) is single domain within a single geographical region and located at a physical location with independent power, network, and cooling. Multiple AZs exist in one region and are connected with each other through a low-latency network. Persisted data using persistence service is automatically hot-replicated to other AZs from one AZ.

Multi-AZ Setup

That means, if one AZ is down for any reason, requests to the services are automatically routed to another AZ. This ensures high availability of the services within a region.

Of course, with the concern that at the moment that one AZ is down, the request sent to the service on that AZ would fail, consider using the popular cloud-native design pattern - "retry".

If it’s still a concern that the whole region can go down, cross-regional high availability can be setup by customer itself.  Refer to this blog post for reference:

Another topic as part of the service assessment is Disaster Recovery. As just stated, the multi-AZ architecture increases the availability of the SAP BTP services. This has made Disaster Recovery not that critical. As a standard default setup, services and their data/configurations are backed up to the AZs within the same region regularly (interval depends on selected hyperscale as data type, such as logs, database, configuration data, etc.) and retained for 14 days (RPO). When one AZ is down, SAP would start the recovery process. The Recovery Time Objective (RTO) is not defined because it really depends on the reason of the “disaster”.


The public cloud BTP services are maintained by SAP. From time to time, SAP performs updates/fixes/upgrades to the services. You can find the maintenance schedules and subscribe to notifications at the SAP Trust Center:

For mission-critical services, whether the services updates are disruptive is to be considered.


Logging and Notification

Services generate logs. While the auditing-related logs are accessible via the SAP BTP Audit Log Service (via API or Dashboard), other service-specific activity logs are written to the log storage selected by the service itself and typically, a featured service provides a log viewer for the service itself.

For the audit logs, the log entries will be retained by SAP BTP for 90 days after which they are deleted.

For other service-specific logs, the service document would provide the retention period of them.

Typically, a BTP service does not provide notification of errors. Service users need to configure or develop notification for critical events. For example, the SAP BTP Alert Notification Service can be used to generate notifications for some audit log entries; the SAP Integration Flow can generate notifications as part of the flow.

I18n and WCAG

While most companies are ok with developing and configuring in English, if a BTP service has end-user-interface, availability of local language needs to be considered. Refer to the service document to see what languages are supported and whether Web Content Accessibility Guidelines (WCAG) is supported if somehow required.



Monthly or annual cost is an important factor when choosing a cloud service. In SAP BTP, each service is priced differently and the way to calculate the cost differs from service to service. Some are based on number of users, some are based on number of service invocations and some may be based on CPU, memory, or storage usage, etc..

A company may subscribe to SAP BTP in one of the two ways: CPEA or Pay-As-You-Go. Under each subscription model, most of the services have a “free tier” service plan which incurs zero cost and can be used for trial, PoC or learning purposes. “free tier” service plans should not be used for QA, Production or even development purposes due to their limitations.

For example, the “SAP Document Management service, integration option” pricing info is as below:

Sample Pricing


For this service, the monthly price is different for CPEA and Pay-As-You-Go SAP BTP subscriptions.

Also price may be different for different regions. This service has two charges: API Calls and Storage Usage.


A relatively accurate price estimation relies on your estimate of the usage of the service based on history and/or prediction for the future usage.


In addition, if one service depends on another and the two services are priced separately, both have to be calculated and totaled up.



SAP BTP has many robust technical and business services to enable companies to achieve project success. Using SAP BTP SaaS services has many advantages over running or creating self-managed services.

There are many criterions when choosing a cloud service to use. This blog post tries to pick a few that are often used and give some hints about where to go to find the relevant information. Hope this helps in assessing a BTP service's applicability.