Exploring SAP BTP Foundation Services

It would be okay to think of foundation services as a core, technical layer of SAP BTP. They are a collection of essential, cross-cutting services that provide the fundamental capabilities required to run, manage, secure, and extend all applications and services on the platform. In some ways they comprise the technical backbone that underpins everything else that organizations do with SAP BTP

It isn't a single service that organizations subscribe to, but rather a set of core entitlements and services that come with their SAP BTP account. A good way to think about these services would be to assign them to the following categories:

• Runtimes & Application Lifecycle Management
• Security & Compliance
• Persistency
• Connectivity
• Administration & Operations

As the saying goes "the whole is greater than the sum of its parts". With that let's explore each of the categories and some of the services contained within in detail.

You may recall that back in Unit 3: Exploring Application Development and Automation Serviceswe discussed at length some of the services offered in this area. For example we discussed the different runtimes that SAP BTP offers developers such as Cloud Foundry and Kyma as well as the SAP Cloud Transport Management service and the HTML Application Repository. A few additional services available are:

• SAP Cloud Logging Service

  The SAP Cloud Logging service is a fundamental, managed service on the SAP Business Technology Platform (BTP) that provides a centralized solution for collecting, storing, viewing, and analyzing logs generated by applications and services running on the platform.

  Think of it as the central nervous system for event information on BTP. Instead of having to access each individual application or service to see what's happening, the Cloud Logging service aggregates all this information into one accessible place. This is a cornerstone of observability, enabling developers, administrators, and support teams to troubleshoot issues, monitor application health, and understand system behavior in real-time.

  SAP Cloud Logging Service is built upon OpenSearch. OpenSearch, as a distributed search and analytics suite, does not define a single, rigid "standard" for logging in the same way a specific protocol or file format might. Instead, it provides a powerful and flexible platform for centralized log management and analysis.

  The primary goals of the SAP Cloud Logging service are to:

  • Centralize Logging: Aggregate logs from various sources (applications, BTP runtimes) into a single, unified log store.
  • Simplify Troubleshooting: Provide powerful tools to search, filter, and analyze log data to quickly identify the root cause of errors and performance issues.
  • Enable Real-time Monitoring: Offer a live stream of logs, allowing developers to see the impact of their code or user activity as it happens.
  • Support Different Environments: Provide consistent logging capabilities across the different BTP environments, primarily Cloud Foundry, Kyma, and the ABAP Environment.
  • Integrate with Other Tools: Allow logs to be forwarded (or "drained") to external, enterprise-grade monitoring and log analysis platforms.

• The service primarily collects two categories of logs:

  • Application Logs: These are generated by your custom applications. In a Java/Node.js app, this would be anything you print to the console (System.out.println, console.log, etc.) or log using a standard logging framework.
  • Platform Logs: These are generated by the BTP runtime components themselves. Examples include logs from the Cloud Foundry router (which handles incoming HTTP requests), the scheduler (Diego), and other system-level components. These are invaluable for diagnosing platform-level issues.

  Important Distinction: The SAP Cloud Logging service is for technical and operational logs. For security-relevant events and compliance auditing (e.g., "who logged in?", "who changed a critical configuration?"), you should use the SAP Audit Log Service, which is a separate service designed specifically for that purpose.

• SAP Job Scheduling Service

  SAP Job Scheduling Service is a fully managed, cloud-native service that allows you to define and manage jobs that run on a recurring schedule or as one-time tasks. It is essentially an enterprise-grade, highly reliable "cron" service for your cloud applications.

  Its primary purpose is to offload the complexity of scheduling, triggering, and monitoring background tasks from your application logic. Instead of building your own scheduling mechanism (which is difficult to make resilient and scalable), you use this service to call your application's endpoints at the desired times.

  It is a foundational service for building robust, automated, and scalable business applications on SAP BTP. Here are its key features:

  • Flexible Scheduling
    • Cron-based Scheduling: Define complex recurring schedules using the standard cron syntax (e.g., "run at 3 PM every weekday").
    • One-Time Jobs: Schedule a task to run once at a specific time in the future.
  • API-Driven: The entire service is manageable via a comprehensive set of REST APIs. This allows for programmatic creation and management of jobs, enabling powerful automation scenarios.
  • User Interface (Dashboard): Provides a simple UI within the BTP Cockpit for monitoring job history, checking logs, and performing manual actions on schedules.
  • Secure Callbacks (Webhooks): The scheduler triggers your job by making an authenticated HTTP/S call (a webhook) to an endpoint you expose in your application.
  • Retry Mechanism: You can configure automatic retries with backoff strategies in case your application endpoint is unavailable or returns an error.
  • Multi-Tenancy Support: The service is designed to work in multi-tenant applications, where you can manage jobs and schedules on behalf of your different consumer tenants.
  • Platform Agnostic: While a core part of SAP BTP, the concept is standard. It can call any reachable HTTP endpoint, though it's primarily used for applications running within BTP.

Imagine your company's entire digital landscape (all your SAP and non-SAP apps) is a massive, exclusive building complex:

• SAP Cloud Identity Services acts as the central security and hospitality desk at the main entrance.
• The Bouncer (Identity Authentication): Checks your ID once. After that, you get a special wristband (Single Sign-On) that lets you enter any room or building (application) you're authorized to access without showing your ID again. If a room requires extra security, the bouncer might ask for a second form of ID (Multi-Factor Authentication).
• The Concierge (Identity Provisioning): When you're hired, the concierge gets a notification. They automatically create your access profile, give you the right keys (user accounts), and ensure your wristband works for the specific areas you need (role assignments). When you leave the company, the concierge deactivates your wristband and all your keys instantly.

SAP Cloud Identity Services (CIS) functions as the digital doorman and ID card system for SAP's entire cloud landscape. It's a fundamental service running on the SAP BTP that handles user identity, authentication (who are you?), and authorization (what are you allowed to do?). Its primary goal is to provide a secure, centralized, and seamless access experience for users across all connected SAP and non-SAP cloud applications.

SAP Cloud Identity Services relationship with SAP BTP is two fold:

• It Secures SAP BTP Itself: When a user logs into the SAP BTP Cockpit to manage services, they are using SAP Cloud Identity Services to authenticate. It protects the platform itself.
• It's a Reusable Service on SAP BTP: Any application that is built, extended, or integrated on BTP can (and should) leverage CIS for user management. This ensures consistency, security, and a better user experience, as a new login system doesn't have to be designed for every new app.

CIS is a bundle of different but complementary services. A few of them are:

• Identity Authentication Service (IAS): This is the component that users directly interact with. Think of it as the "front door". Its main job is to verify a user's identity.

  Key Functions of IAS:

  • Single Sign-On (SSO): This is its most significant benefit. A user logs in once to IAS and can then access all connected applications (like SAP Cloud ERP, SAP SuccessFactors, SAP Ariba, SAP Concur, and custom BTP apps) without re-entering their credentials.
  • User Authentication: Provides various methods for logging in, including:
    • Username and Password
    • Multi-Factor Authentication (MFA): Adds a layer of security by requiring a second verification step (e.g., a code from an authenticator app).
    • Social Logins (e.g., Google, LinkedIn).
  • Identity Federation: IAS can act as a proxy. It can connect to a company's existing corporate identity provider (like Microsoft Azure AD, Okta, or PingFederate). In this scenario, the user logs in with their familiar corporate credentials, Azure AD authenticates them, and IAS trusts that authentication to grant access to SAP applications.
  • Branding and Customization: Allows companies to customize the login screen with their own logo and branding for a consistent user experience.
• Identity Provisioning Service (IPS): This is the component that works "behind the scenes". Its job is to synchronize user identities and their permissions across different systems automatically.

  Key Functions of IPS

  • Automated User Lifecycle Management: When a new employee joins, they are created in the HR system (e.g., SAP SuccessFactors). IPS can automatically detect this and:
    • Create the user account in Identity Authentication (IAS).
    • Create the user account in other target systems like SAP Cloud ERP, assigning them initial roles.
  • Centralized Role Management: When an employee changes roles or leaves the company, IPS ensures their access rights are updated or revoked across all connected systems automatically. This is crucial for security and compliance.
  • Source and Target Systems: IPS reads user data from a "source" system (often an HR system like SAP SuccessFactors or even Microsoft Azure AD) and writes (provisions) it to multiple "target" systems (SAP cloud apps, custom BTP apps, etc.).
• SAP Authorization and Trust Management Service: This service It handles two critical security functions:
  • Trust Management: Establishing trust with an Identity Provider (IdP) to verify who a user is (Authentication).
  • Authorization: Determining what a user is allowed to do within an application (e.g., view data, approve a request, delete a record).

  To understand its role, imagine a secure corporate building:

  • Authentication (The "Trust" Part) To enter the building, you need an ID badge. This badge is issued by a trusted source, like HR (your Identity Provider). The security guard at the front desk (the SAP Authorization and Trust Management service) doesn't create your identity; it simply trusts the badge issued by HR to verify you are who you say you are. You can use a badge from your own company (a corporate IdP) or a visitor pass (the default SAP ID Service).
  • Authorization (The "Authorization" Part) Once inside, your badge doesn't grant you access to every room. Your job role (e.g., "Finance Manager") determines which doors you can open. This "Finance Manager" profile is a Role Collection in BTP. It might grant you access to the finance floor (an application role) and the key to the main accounts office (an application scope like "ReadFinancials"). The SAP Authorization and Trust Management service is what loads these permissions onto your badge when you enter.

SAP BTP distinguishes between platform users and business users:

• Platform users are usually administrators or operators (DevOps) who work with cloud management tools and deploy, administer, and troubleshoot services on SAP BTP. These are usually users who directly log on to the SAP BTP cockpit and work there. They can also be developers who work and use services in, for example, the Cloud Foundry environment.
• Business users are end users of business applications that are deployed on SAP BTP. These can also be users of subscribed services, such as SAP Business Application Studio, who work in the application directly and not via the SAP BTP cockpit. Custom extensions deployed by organiztions are typically also consumed by business users.

This differentiation between business and platform users is just on a logical level based on the authorizations a user receives. There's no technical difference between these two types of users. In reality, platform users may also have authorizations of business users but never the other way around.

With this understanding let's trace a new employee's journey to see how CIS works in practice:

• Onboarding: An HR administrator creates a profile for a new employee, "Anna," in SAP SuccessFactors.
• Provisioning (IPS): The Identity Provisioning Service (IPS) is configured to monitor SAP SuccessFactors. It detects the new user, Anna.
• Account Creation (IPS -> IAS & Apps): IPS automatically creates an account for Anna in the Identity Authentication Service (IAS) and also in SAP Cloud ERP with a "New Hire" role.
• First Login (IAS): Anna receives her credentials. She navigates to the SAP Cloud ERP URL.
• Authentication Redirect: The SAP Cloud ERP application, being secured by BTP, redirects her to the company's branded IAS login page.
• SSO in Action: Anna logs into IAS once. IAS confirms her identity. She is now logged into SAP Cloud ERP.
• Seamless Access Later, Anna needs to access a custom-built BTP application. When she clicks the link, the app checks with IAS, sees she already has an active session, and grants her access immediately without asking for a password again.
• Offboarding: A year later, Anna leaves the company. Her status is updated in SAP SuccessFactors. IPS detects this change and automatically deactivates her accounts in IAS, SAP Cloud ERP, and all other target systems, instantly revoking her access.

In today's digital landscape, businesses face several critical challenges regarding their data:

• Regulatory Compliance: Laws like GDPR (General Data Protection Regulation) and CCPA (California Consumer Privacy Act) mandate strict rules on how long personal data can be stored and when it must be deleted (e.g., the "right to be forgotten"). Non-compliance leads to heavy fines.
• Data Volume Growth: Some cloud applications might generate massive amounts of data. Storing unnecessary historical data increases costs, degrades system performance, and complicates data management.
• Legal Requirements: Companies must be able to place "legal holds" on specific data, preventing its deletion during litigation or investigations, even if its planned retention period has expired.
• Consistency Across a Hybrid Landscape: Many companies use a mix of cloud and on-premise systems. They need a unified strategy for data retention that works across this distributed environment.

SAP Data Retention Manager (DRM) is a service available on SAP BTP. Its primary purpose is to manage the complete lifecycle of business data, from creation to final deletion, in a consistent, automated, and compliant manner. Some use cases where DRM could be useful are:

• GDPR Compliance in SAP Cloud ERP: A European customer requests their data be deleted. The company uses DRM to trigger the blocking and eventual deletion of all related business partner data, sales orders, and invoices in SAP Cloud ERP, respecting all financial and legal minimum retention periods.
• Managing Employee Data in SuccessFactors: An HR department sets a policy in DRM to automatically delete the application data of unsuccessful job candidates 6 months after the position is filled.
• Legal Hold for an Ex-Employee: A company is involved in a lawsuit with a former employee. The legal department uses DRM to place a legal hold on all of that employee's data in SAP SuccessFactors and any related SAP Cloud ERP records, preventing its scheduled deletion.
• Custom BTP App Data Management: A logistics company builds a custom "Proof of Delivery" app on BTP. They use DRM to define a policy to automatically delete delivery photos and signatures 2 years after successful delivery to reduce storage costs on BTP.

We talked in detail about SAP HANA Cloud in Unit 4 Lesson 1: Exploring Data and Analytics Services.Some other persistency services available are:

• Object Store on SAP BTP: Object stores excel at managing unstructured data like images, videos, audio files, documents, and logs, which are not easily organized within the rigid schema of a relational database. Object Store on SAP BTP operates as a "middleware" to allow an application to bind to an object store service. The specific object store service depends on the underlying IaaS platform (e.g. Azure Blob Service for Microsoft Azure) .
• PostgreSQL on SAP BTP, hyperscaler option: While SAP HANA Cloud is the preferred relational database for SAP BTP, for those use cases where a different relational database is needed the PostgreSQL service, similar to Object Store on SAP BTP allows an application to bind to the relational database offered by the underlying hyperscaler (e.g., GCP Cloud SQL for PostgreSQL).
• Redis on SAP BTP, hyperscaler option: Redis is an open-source, in-memory data structure store used primarily as a database, cache, message broker, and streaming engine. As with the previous two services mentioned an application using this service can bind to the underlying hyperscale option (e.g., AWS ElastiCache for Redis).

There are two main services to note in the connectivity category, SAP Connectivity Service and SAP Destination Service:

• SAP Connectivity Service acts as a secure and reliable "bridge" between applications running on SAP BTP and on-premise systems. Its primary purpose is to solve the complex challenge of securely connecting cloud applications to private, firewalled networks without compromising enterprise security policies. It essentially creates a secure "tunnel" that allows for seamless communication.

  The service consists of two main parts that work together:

  • Connectivity Service (Cloud Side): This is the service running on SAP BTP. It acts as a proxy, managing connection configurations, security credentials, and routing requests from SAP BTP applications to the appropriate remote system.
  • Cloud Connector (On-Premise Side): This is a lightweight, reverse-invoke proxy agent that is installed and is running within a secure on-premise network. It's a critical piece of the puzzle because it initiates an outbound connection from an organizations network to SAP BTP.

• Imagine you're building an application. This application needs to call other services to get data—for example, a currency conversion API, a weather service, or your company's internal SAP Cloud ERP. Without the Destination Service, you would have to hardcode the URLs, usernames, passwords, and other technical connection details directly into your application's code. This is a terrible practice: it's insecure, hard to maintain, and inflexible. The SAP Destination Service acts as a centralized and secure "Address Book" or "Contact List" for applications running on SAP BTP. Instead of hardcoding connection details, an application simply asks the Destination Service: "Hey, I need to connect to the 'SAP Cloud ERP_SalesOrders' system. Can you give me the details?" The service then provides the necessary information securely at runtime.

Some of the use cases for these two services would include:

• A custom Fiori app on SAP BTP displaying real-time sales orders from an on-premise ERP.
• An SAP Integration Suite flow that picks up a file from an on-premise SFTP server, transforms it, and posts an invoice to an on-premise SAP ERP system via RFC.
• An SAP Build Apps application that allows employees to update their HR data, which calls APIs in SAP SuccessFactors (since SAP SuccessFactors is cloud based only SAP Destination Service is needed).
• A machine learning service on SAP BTP being trained with large datasets pulled from an on-premise data warehouse.

Finally as part of the Administration & Operations category let's take a look at two services:

• SAP Alert Notification service for SAP BTP
• SAP Usage Data Management Service for SAP BTP

SAP Alert Notification service for SAP BTP

Imagine your SAP BTP landscape is a bustling city with many different buildings (applications, services, runtimes). Each building has its own alarm system. Without a central dispatcher, you'd need to manually monitor every single alarm panel in every building. SAP Alert Notification service is that central dispatcher. It receives all the different alarms (events) from every building, understands which ones are important based on your rules, and instantly notifies the right people (developers, operators) on their preferred channel (email, Slack, Microsoft Teams, etc.).

Applying this analogy to a complex cloud environment, events happen constantly:

• An application might crash.
• A database might be running out of storage.
• A security certificate is about to expire.
• A long-running job has failed.

Without a centralized service, you would have to:

• Manually check logs and dashboards across multiple services.
• Build custom notification logic into every single application.
• Deal with different event formats and severities from each source.

This is inefficient, error-prone, and leads to slower response times. SAP Alert Notification service for SAP BTP solves this by decoupling event production from notification consumption. More specifically SAP Alert Notification service for SAP BTP enables the sending of alerts and notifications to various channels, such as email, SMS, or third-party messaging services. This service is particularly useful for keeping users informed about important events, system statuses, or any other relevant information related to their SAP environment.

Common Use Cases For SAP Alert Notification service for SAP BTP:

• Application Health Monitoring:

  • Scenario: A critical Node.js application in your Cloud Foundry production space crashes.
  • Flow: Cloud Foundry sends an AppCrash event -> Alert Notification matches a condition for eventType == 'AppCrash' -> It triggers an action that posts a high-priority message to the #dev-ops-alerts Slack channel and creates a P1 incident in ServiceNow.
• Security Management:
  • Scenario: An X.509 certificate used for an integration is due to expire in 14 days.
  • Flow: SAP BTP Security service sends a Certificate_Expiry event -> Alert Notification matches a condition for eventType -> It triggers an action to email the security administration team.
• Quota Management:
  • Scenario: Your Cloud Foundry organization is about to exceed its memory quota.
  • Flow: The platform sends a quota-related event -> Alert Notification catches it and notifies the BTP platform owner via Microsoft Teams to request a quota increase.

SAP Usage Data Management Service for SAP BTP

Think of the SAP Usage Data Management Service as the utility meter for your applications running on SAP BTP. Just like your electric company uses a meter to track how much electricity you consume to bill you accurately, this service allows application developers to track how much their services are being used by different consumers (tenants).

The SAP Usage Data Management service for SAP BTP provides REST APIs that are responsible for gathering, storing, and making usage information available for all services and applications in all regions in a cloud deployment, for the purpose of central analysis, reporting, and license auditing. The service accumulates the information and provides reports in several business systems (reporting and operations) for resource planning and cross billing purposes. Customers can also see their usage data in the SAP BTP cockpit, for example, in the Usage Analytics pages.