Sap Btp Best Practices

SAP BTP Best Practices

Related Skills

• sap-btp-cloud-platform: Use for technical implementation details, CLI commands, and runtime configurations
• sap-btp-connectivity: Use for connectivity patterns, destination configuration, and Cloud Connector setup
• sap-btp-service-manager: Use for service lifecycle management and programmatic service operations
• sap-btp-developer-guide: Use for development workflows, CAP integration, and application patterns
• sap-cap-capire: Use when designing CAP applications on BTP or implementing multitenancy
• sap-ai-core: Use for AI Core platform setup, model deployment, and orchestration configuration
• sap-cloud-sdk-ai: Use for SDK-level AI integration in CAP or standalone BTP applications
• sap-fiori-tools: Use for UI deployment strategies and frontend application guidelines

When to Use This Skill

Use this skill when designing a BTP account model, setting up governance, choosing commercial/environment patterns, establishing security and authentication defaults, designing CI/CD and operations practices, or reviewing a BTP landscape before implementation.

Quick Start

1. Identify the target account model: global account, directories, subaccounts, environments, and regions. 2. Choose the runtime path: Cloud Foundry, Kyma, ABAP Environment, or a hybrid portfolio. 3. Apply security defaults from Security and Authentication. 4. Use the relevant implementation skill for detailed execution: sap-btp-cloud-platform, sap-btp-connectivity, sap-btp-service-manager, sap-cap-capire, or sap-fiori-tools. 5. Record production-specific gaps in the project plan before changing last_verified.

Documentation-audited SAP BTP implementation guidance based on official SAP documentation. The last_verified date remains stale until the source refresh and any live account checks are completed.

Quick Links:

• Official Guide: https://github.com/SAP-docs/btp-best-practices-guide
• SAP Help Portal: https://help.sap.com/docs/btp/btp-administrators-guide

---

Table of Contents

1. Platform Fundamentals 2. Account Model Setup 3. Security and Authentication 4. Connectivity 5. Governance and Teams 6. Development 7. AI Development 8. Deployment and Delivery 9. High Availability and Failover 10. Operations and Monitoring 11. Cost Management 12. Bundled Resources

---

Platform Fundamentals

Account Hierarchy

Global Account (SAP contract)
├── Directory (optional, up to 7 levels)
│   └── Subaccount (region-specific, apps run here)
│       ├── Cloud Foundry Org → Spaces
│       └── Kyma Cluster → Namespaces
└── Subaccount

Key Points:

• Global account = contract with SAP (one per commercial model)
• Directory = groups subaccounts (max 7 levels deep)
• Subaccount = deployed in specific region, enables runtimes
• Use labels for virtual grouping (Dev/Test/Prod, cost centers)

Environments

Commercial Models

• Consumption-Based (BTPEA/CPEA): Flexible access, best for pilots
• Subscription-Based: Fixed-cost for known service needs

Best Practice: Start with consumption-based, move to subscription for stable workloads.

---

Account Model Setup

Simple Model (3 subaccounts)

Global Account
├── Dev Subaccount
├── Test Subaccount
└── Prod Subaccount

Best for: Initial implementations, single team, <3 projects

Directory Model (scalable)

Global Account
├── Directory: HR
│   ├── hr-dev / hr-test / hr-prod
├── Directory: Sales
│   ├── sales-dev / sales-test / sales-prod
└── Directory: Central IT
    ├── api-management
    └── shared-services

Best for: Multiple teams, cost allocation, complex governance

Naming Conventions

Tip: Derive CF org/Kyma names from subaccount names for consistency.

---

Security and Authentication

Identity Provider Setup

Always use SAP Cloud Identity Services - Identity Authentication

Corporate IdP → Identity Authentication (proxy) → SAP BTP

Critical Steps: 1. Add multiple administrators (different time zones) 2. Enable MFA for all admins 3. Configure security alerts 4. Set up backup admins in SAP ID Service

Authorization Methods

Destination Authentication

Recommended:

• PrincipalPropagation - SAP on-premise systems
• OAuth2SAMLBearerAssertion - Third-party systems
• OAuth2JWTBearer - User token exchange

Avoid in Production:

• BasicAuthentication
• OAuth2Password

See: references/security-and-authentication.md for complete guidance

---

Connectivity

Remote System Access

• Internet Services: Destinations with authentication
• On-Premise Systems: Destinations + Cloud Connector

Cloud Connector

• Lightweight on-premise agent
• Secure tunnel to SAP BTP (no inbound ports)
• Fine-grained access control
• Supports RFC and HTTP protocols
• Enables principal propagation

Note: Each subaccount needs separate Cloud Connector config.

---

Governance and Teams

Required Teams

Platform Engineering Team (Center of Excellence):

• Manages cloud landscape infrastructure
• Handles account operations, build infrastructure
• Creates governance and compliance guidelines
• Does NOT manage individual application lifecycles

Cloud Development Teams:

• Follow DevOps (develop AND operate)
• Responsible for application lifecycle
• Regular maintenance (e.g., UI updates every 6 months)

Essential Documentation

1. Onboarding Doc: Organization, app IDs, timeline, tech stack 2. Security Doc: Data sensitivity, policies, auth framework 3. Services Catalog: Templates for destinations, builds, schemas

---

Development

Programming Models

SAP CAP (Cloud Application Programming Model):

• Framework with languages, libraries, tools
• Supports Java, JavaScript, TypeScript
• Enterprise-grade services and data models

ABAP Cloud:

• Modern ABAP for cloud-ready apps
• RAP (RESTful ABAP Programming Model)
• Extensions for ABAP-based products

Development Lifecycle

1. Explore: Business opportunity, team roles 2. Discover: Use cases, technology options 3. Design: UX design, domain-driven design 4. Deliver: Landscape setup, development 5. Run and Scale: Feedback, optimization

---

AI Development

SAP BTP provides AI capabilities through SAP AI Core for:

• Generative AI (LLMs, RAG)
• Narrow AI (classical ML)

Key Resources:

• Repository: SAP-samples/sap-btp-ai-best-practices
• Documentation: https://btp-ai-bp.docs.sap/

Best Practices:

• Use service keys for secure authentication
• Implement PII data masking
• Build RAG with SAP HANA Cloud Vector Engine
• Configure content filtering
• Monitor model drift

Use Cases: 20+ samples including chatbots, PDF extraction, procurement.

CAP + AI Integration Patterns:

• Use SAP Cloud SDK for AI (@sap-ai-sdk/orchestration) inside CAP event handlers — never raw HTTP calls to LLM providers
• Bind AI Core service instance to CAP app via MTA (plan: extended) — credentials are managed by BTP, not in code
• Always process LLM calls asynchronously in production: return 202 Accepted, process in background via cds.spawn. LLM responses can take 30-60 seconds, exceeding BTP load balancer timeouts
• Externalize prompts into JSON files or CDS entities so they can be updated without redeployment
• Use HANA Cloud Vector(1536) type in CDS entities for RAG scenarios with the HANA Vector Engine
• Allocate at least 512MB memory for Node.js containers processing large text payloads with the AI SDK
• Implement resilience: validate LLM outputs before writing to the database (prevent injection attacks), cache frequent responses for cost control

See: references/ai-development-best-practices.md for patterns and examples. For CAP-specific code patterns, see sap-cap-capire skill. For SDK integration, see sap-cloud-sdk-ai skill.

---

Deployment and Delivery

Deployment Methods

Cloud Foundry/Neo:

• Package as MTA archive
• Deploy via: BTP Cockpit, CF CLI, Business Application Studio

Kyma:

• Docker images (Dockerfile or Cloud Native Buildpacks)
• Helm charts for production
• Deploy via SAP Continuous Integration and Delivery

CI/CD Approaches

SAP Continuous Integration and Delivery:

• Low expertise required
• Ready-to-use infrastructure
• Direct SAP support

Project "Piper":

• High expertise required
• Jenkins-based
• Open-source community support

Best Practice: Combine CI/CD with SAP Cloud Transport Management for governance + agility.

See: references/deployment-and-delivery.md for detailed configs

---

High Availability and Failover

Multi-Region Architecture

Custom Domain URL
       │
    Load Balancer
       ├── Region 1 (active)
       └── Region 2 (passive/active)

Failover Implementation

Four Core Principles:

1. Deploy in Two Regions: Near users and backend systems 2. Keep Synced: CI/CD pipeline or Cloud Transport Management 3. Define Detection: Monitor 5xx errors, timeouts 4. Plan Failback: Visual differentiation, user-driven

Legal: Check cross-region data processing restrictions.

See: references/failover-and-resilience.md for implementation details

---

Operations and Monitoring

Go-Live Checklist

1. Deploy to production 2. Set go-live timeframe (avoid quarter-end) 3. Embed in SAP Fiori Launchpad 4. Provision business users 5. Configure role collections

Monitoring Tools

SAP Cloud ALM (Enterprise Support):

• Real User Monitoring
• Health Monitoring
• Integration and Exception Monitoring
• Job Automation Monitoring

SAP Cloud Logging:

• Observability across CF, Kyma, Kubernetes

SAP Alert Notification:

• Multi-channel notifications (email, chat, ticketing)

---

Cost Management

Best Practices

1. Check Costs and Usage monthly 2. Provide minimal required entitlements 3. Use labels for cost allocation 4. Set up automated alerts (Usage Data Management + Alert Notification)

Contract Strategies

• Consolidate subscriptions in one global account
• Use hybrid accounts for mixed workloads
• Note: Consumption credits non-transferable between global accounts

---

Bundled Resources

This skill provides comprehensive reference documentation:

Account & Governance

• `references/account-models.md` (11K lines)
• Detailed account structure patterns
• Naming conventions and examples
• Cost allocation strategies

• `references/governance-and-teams.md` (13K lines)
• Platform Engineering team structure
• Onboarding processes
• Documentation templates

Security & Connectivity

• `references/security-and-authentication.md` (13K lines)
• Complete auth methods comparison
• Destination configuration
• Kyma RBAC manifests
• Identity lifecycle management

Deployment & Operations

• `references/deployment-and-delivery.md` (10K lines)
• MTA descriptor templates
• CI/CD pipeline configs
• Transport management setup

• `references/operations-and-monitoring.md` (11K lines)
• Go-live procedures
• Monitoring setup guides
• Troubleshooting checklists

High Availability

• `references/failover-and-resilience.md` (12K lines)
• Multi-region architecture
• Load balancer configurations
• Failover automation scripts

Templates & Examples

• `references/templates-and-examples.md` (18K lines)
• Complete code templates
• Kubernetes RBAC manifests
• MTA descriptors
• Helm charts
• CI/CD configs

AI Development

• `references/ai-development-best-practices.md` (6K lines)
• Generative AI patterns
• RAG implementation
• 20+ use cases catalog

Progress Tracking

• Implementation status
• Coverage details
• Validation checklists

---

Administration Tools

---

Shared Responsibility Model

SAP Manages:

• Platform software updates/patches
• Infrastructure and OS monitoring
• BTP service monitoring
• Capacity management and incidents
• Global account provisioning
• HANA database operations
• Kyma kyma-system namespace

You Manage:

• Global account strategy and subaccount config
• Application development, deployment, security
• Role assignments and integrations
• Application monitoring and health checks
• Open source vulnerability scanning
• Triggering HANA revision updates

---

Last Updated: 2026-06-16 Review Progress: See SAP_SKILLS_REVIEW_PROGRESS.md Next Review: Source refresh pending; do not advance last_verified without primary-source evidence.

SAP BTP Best Practices Skill

Comprehensive best practices for SAP Business Technology Platform (BTP) implementation, covering enterprise cloud architecture, account management, security, deployment, and operations.

Overview

This skill provides documentation-audited guidance for SAP BTP implementations based on the official SAP BTP Administrator's Guide and Best Practices documentation. Its last_verified date is intentionally stale until the source refresh and any live account checks are completed.

Source Documentation: https://github.com/SAP-docs/btp-best-practices-guide

Version: 2.3.0 Last Verified: 2025-11-27

---

Capability Index

Keywords for Discovery

Platform and Architecture

• SAP BTP
• SAP Business Technology Platform
• BTP architecture
• BTP account model
• global account
• subaccount
• directory
• BTP cockpit
• btp CLI
• multi-cloud
• Cloud Foundry
• CF environment
• Kyma
• Kyma environment
• ABAP environment
• Neo environment
• BTP region
• BTP services
• entitlements
• quotas

Account Management

• account hierarchy
• account structure
• subaccount setup
• directory structure
• account model
• naming conventions
• BTP naming
• staged development
• dev test prod
• development subaccount
• production subaccount
• CF spaces
• Kyma namespaces
• labels
• account administration

Security and Authentication

• SAP Cloud Identity Services
• Identity Authentication
• IAS
• identity provider
• IdP configuration
• SSO
• single sign-on
• principal propagation
• user federation
• identity provisioning
• identity lifecycle
• platform users
• business users
• role collections
• RBAC
• role-based access control
• authorization
• authentication
• MFA
• multifactor authentication
• SAP ID Service
• trust configuration
• destination authentication
• OAuth
• SAML

Connectivity

• Cloud Connector
• destinations
• remote systems
• on-premise connectivity
• hybrid connectivity
• mTLS
• certificates
• destination service
• connectivity service
• API management

Deployment and Delivery

• MTA
• multitarget application
• deployment
• CI/CD
• continuous integration
• continuous delivery
• SAP Continuous Integration and Delivery
• Project Piper
• transport management
• SAP Cloud Transport Management
• CTS+
• Helm charts
• Docker
• containerization
• buildpacks

Operations and Monitoring

• SAP Cloud ALM
• monitoring
• alerting
• Alert Notification Service
• Job Scheduling Service
• Cloud Logging
• health monitoring
• real user monitoring
• observability
• automation
• SAP Automation Pilot
• go-live
• operations

High Availability and Resilience

• failover
• high availability
• HA
• disaster recovery
• multi-region
• active passive
• active active
• data backup
• resilience
• redundancy
• load balancing

Governance and Teams

• Platform Engineering Team
• Cloud Development Team
• Center of Excellence
• CoE
• governance model
• onboarding
• knowledge transfer
• DevOps
• shared responsibility
• cost management
• billing
• compliance
• data protection
• GDPR

Commercial Models

• consumption-based
• subscription-based
• BTPEA
• CPEA
• Pay-As-You-Go
• free tier
• enterprise account

Integration

• SAP Cloud Integration
• integration testing
• OPA5
• SAPUI5 testing
• Cloud Integration Automation

Lifecycle Management

• application lifecycle
• maintenance
• retirement
• Neo migration
• updates
• blue-green deployment
• feature flags

AI and Machine Learning

• SAP AI Core
• generative AI BTP
• RAG BTP
• LLM BTP
• prompt engineering SAP
• content filtering AI
• data masking PII
• anomaly detection BTP
• SAP Document AI
• AI use cases BTP
• agentic AI SAP
• vector embeddings SAP
• SAP HANA Cloud Vector Engine

---

Use This Skill When

1. Planning SAP BTP Implementation

• Setting up a new SAP BTP landscape
• Designing account hierarchy
• Choosing commercial models
• Planning team structure

2. Configuring Account Structure

• Creating directories and subaccounts
• Setting up staged development environments
• Defining naming conventions
• Managing entitlements and quotas

3. Implementing Security

• Configuring SAP Cloud Identity Services
• Setting up authentication
• Implementing authorization
• Configuring destinations and Cloud Connector

4. Deploying Applications

• Building MTA archives
• Setting up CI/CD pipelines
• Configuring transport management
• Deploying to Cloud Foundry or Kyma

5. Operating BTP Landscape

• Setting up monitoring
• Configuring alerts
• Managing costs
• Planning go-live

6. Implementing High Availability

• Designing multi-region architecture
• Implementing failover
• Planning disaster recovery

7. Building AI Solutions

• Implementing generative AI with SAP AI Core
• Building RAG systems
• Configuring content filtering and PII protection
• Deploying anomaly detection models

---

Skill Contents

Main File

• SKILL.md - Core best practices organized by lifecycle phase (~4000 words)

Reference Files (Progressive Disclosure)

Located in references/ directory:

• account-models.md - Detailed account structure patterns and examples
• security-and-authentication.md - Complete security guidance
• deployment-and-delivery.md - CI/CD and transport management details
• failover-and-resilience.md - Multi-region and failover implementation
• operations-and-monitoring.md - Go-live and monitoring procedures
• governance-and-teams.md - Team structure and processes
• templates-and-examples.md - Complete code templates: Kubernetes RBAC manifests, MTA descriptors, Helm charts, CI/CD pipeline configs, multi-region GitHub links
• ai-development-best-practices.md - AI patterns: Generative AI, RAG, content filtering, 20+ use cases catalog

Tracking

---

Source Documentation

This skill is based on content from:

Primary Source:

• https://github.com/SAP-docs/btp-best-practices-guide

SAP Help Portal:

• https://help.sap.com/docs/btp/btp-administrators-guide

Related Resources:

• SAP Discovery Center: https://discovery-center.cloud.sap/
• SAP Developer Center: https://developers.sap.com/
• SAP Community: https://community.sap.com/

---

Updates and Maintenance

Update Schedule

• Quarterly Review: Check for documentation updates
• On SAP Release: Review for new features and changes
• Next Review: 2026-02-21

How to Update

1. Check source repository for changes 3. Update relevant files in skill 4. Update version in SKILL.md frontmatter

---

License

GPL-3.0 License - See repository LICENSE file.

---

Related Skills

• sap-cap - SAP Cloud Application Programming Model
• sap-fiori - SAP Fiori development
• sap-cloud-foundry - Cloud Foundry specific guidance
• sap-kyma - Kyma environment specific guidance
• sap-hana-cloud - SAP HANA Cloud development

---

Maintained by: Eduard Jiglau Email: [hello@sap-ai-skills.com](mailto:hello@sap-ai-skills.com) Website: [sap-ai-skills.com](https://sap-ai-skills.com) Repository: [https://github.com/secondsky/sap-skills](https://github.com/secondsky/sap-skills*)

SAP BTP Account Models - Detailed Reference

Source: https://github.com/SAP-docs/btp-best-practices-guide/tree/main/docs/set-up-and-plan

---

Account Hierarchy Deep Dive

Global Accounts

Global accounts are region and runtime-independent entities representing contracts with SAP:

• Administrators manage subaccounts, members, entitlements, and quotas
• Typically one global account per commercial model
• Separate billing per global account
• Multiple global accounts may be needed for legal or commercial separation

Commercial Contract Options:

• Consumption-Based: BTPEA, CPEA, Pay-As-You-Go (cannot mix flavors)
• Subscription-Based: Fixed-cost for 1-3 year periods

Directories

Directories group subaccounts for organized management and can nest up to 5 levels deep.

Directory Use Cases: 1. Administrative Organization: By subsidiary, department, or line of business 2. Billing and Accounting: Align with financial structure 3. Geographical Grouping: Regulatory compliance and performance optimization 4. Business Scenario Alignment: Group by project or initiative 5. Resource Control: Usage limitations and quota management 6. Technical Organization: Based on infrastructure constraints

Subaccounts

Subaccounts are individual operational units where applications run and services are consumed:

• Deployed in exactly one region
• Can enable multiple runtime environments
• Support dedicated identity provider configuration
• Independent quota and user management

Labels

Labels are user-defined tags for organizing directories, subaccounts, instances, and subscriptions:

• Landscape designations: Dev, Test, Prod
• Departments: HR, IT, Finance, Sales
• Cost center codes
• Custom tags: "Flagged for deletion", "Important"

Best Practice: Use directories as primary structure, labels for virtual grouping and reporting.

---

Account Model Templates

Template 1: Directories Per Functional Area

Global Account
├── Directory: HR
│   ├── Subaccount: hr-development
│   │   └── Identity Provider: Corporate IdP
│   ├── Subaccount: hr-test
│   │   └── Identity Provider: Corporate IdP
│   └── Subaccount: hr-production
│       └── Identity Provider: Corporate IdP (hardened)
├── Directory: Sales
│   ├── Subaccount: sales-development
│   ├── Subaccount: sales-test
│   └── Subaccount: sales-production
└── Directory: IT Services
    ├── Subaccount: shared-services-dev
    ├── Subaccount: shared-services-test
    └── Subaccount: shared-services-prod

Benefits:

• Clear functional separation
• Independent entitlement management per directory
• Easy cost allocation by department

Template 2: Directories Per Location

Global Account
├── Directory: Europe
│   ├── Labels: Region=EU, Compliance=GDPR
│   ├── Subaccount: eu-development (Frankfurt)
│   ├── Subaccount: eu-test (Frankfurt)
│   └── Subaccount: eu-production (Frankfurt)
├── Directory: North America
│   ├── Labels: Region=NA
│   ├── Subaccount: na-development (Virginia)
│   ├── Subaccount: na-test (Virginia)
│   └── Subaccount: na-production (Virginia)
└── Directory: APAC
    ├── Labels: Region=APAC
    ├── Subaccount: apac-development (Singapore)
    ├── Subaccount: apac-test (Singapore)
    └── Subaccount: apac-production (Singapore)

Benefits:

• Regulatory compliance (data residency)
• Performance optimization (proximity to users)
• Regional legal requirements

Template 3: Directories Per Subsidiary

Global Account
├── Directory: ACME Corp
│   ├── Labels: CostCenter=CC001, Owner=John
│   └── Subaccounts: acme-dev, acme-test, acme-prod
├── Directory: ACME Manufacturing
│   ├── Labels: CostCenter=CC002, Owner=Jane
│   └── Subaccounts: acme-mfg-dev, acme-mfg-test, acme-mfg-prod
└── Directory: ACME Services
    ├── Labels: CostCenter=CC003, Owner=Bob
    └── Subaccounts: acme-svc-dev, acme-svc-test, acme-svc-prod

Benefits:

• Clear subsidiary boundaries
• Cost allocation to legal entities
• Independent ownership and management

---

Simple Subaccount Model (Without Directories)

For initial implementations or smaller organizations:

Global Account
├── Subaccount: Development
│   ├── Labels: Stage=Dev, CostCenter=IT
│   └── Identity Provider: Corporate IdP
├── Subaccount: Test
│   ├── Labels: Stage=Test, CostCenter=IT
│   └── Identity Provider: Corporate IdP
└── Subaccount: Production
    ├── Labels: Stage=Prod, CostCenter=IT
    └── Identity Provider: Corporate IdP (hardened)

When to Use:

• Less than 3 projects
• Single team
• Initial BTP adoption

Upgrade Path: Transition to directory model when exceeding 3 subaccounts.

---

Specialized Subaccount Patterns

Separate API Management Subaccounts

Global Account
├── Directory: Central IT Tools
│   ├── Subaccount: api-management-dev
│   ├── Subaccount: api-management-test
│   └── Subaccount: api-management-prod
├── Directory: Shared Data
│   ├── Subaccount: hana-dev-test (shared HANA Cloud)
│   └── Subaccount: hana-production
└── Directory: Projects
    ├── Subaccount: project-a-dev
    ├── Subaccount: project-a-test
    ├── Subaccount: project-a-prod
    └── ... (consume APIs via destinations)

Benefits:

• Centralized API governance
• Shared database costs
• Rapid scaling with API-based connections

Large Project Separation

Global Account
├── Subaccount: development (standard)
├── Subaccount: test (standard)
├── Subaccount: production (standard)
└── Subaccount: project-x-all-stages
    └── (Completely separated support and operations model)

Use When:

• Project requires isolated operations
• Different SLA requirements
• Separate support processes

---

Cloud Foundry Staging Details

Subaccount-Org Relationship

When Cloud Foundry is enabled, the system automatically creates a corresponding CF org with a 1:1 relationship:

Subaccount: hr-development
    └── CF Org: acme-hr-development (auto-created)
        ├── Space: recruiting
        ├── Space: payroll
        └── Space: benefits

Configuration Capabilities Comparison

Data Segregation

Data access is controlled at subaccount level, not application or space level:

• Services consume messages from ALL applications within a subaccount
• Use separate subaccounts to restrict cross-application visibility
• Spaces are for organization when dedicated user management isn't required

---

Kyma Staging Details

Subaccount-Cluster Relationship

Each subaccount provisions exactly one Kubernetes cluster:

Subaccount: platform-dev-test
    └── Kyma Cluster (auto-provisioned)
        ├── Namespace: hr-dev
        ├── Namespace: hr-test
        ├── Namespace: sales-dev
        └── Namespace: sales-test

Subaccount: platform-production
    └── Kyma Cluster
        ├── Namespace: hr
        └── Namespace: sales

Subaccounts vs Namespaces Decision Framework

Use Separate Subaccounts When:

• Data access isolation required
• Different network connectivity needs
• Dedicated user management necessary
• Separate billing/cost tracking required
• Ingress traffic isolation needed

Use Namespaces When:

• Structuring within cluster sufficient
• Trust exists between teams
• Cost efficiency priority
• Development/testing environments

Configuration Comparison

---

Account Model Setup Checklist

Prerequisites

• [ ] Review SAP Cloud Identity Services onboarding guide
• [ ] Assess organizational needs for account model selection
• [ ] Test hierarchy with pilot project managers
• [ ] Familiarize teams with administration tools

Ownership Structure

Directory Template Requirements

When creating new directories, document:

• Name (following naming guidelines)
• Minimum two owners
• Description of developer audience and applications
• Cost center allocation
• Enrollment procedures

Rules to Define

1. Directory creation criteria 2. Naming conventions (see naming guide) 3. Labels and values for reporting 4. Quota limitations per directory/subaccount 5. Entitlement distribution rules

---

Naming Convention Details

Character Restrictions

• Use lowercase letters and hyphens
• Avoid spaces and underscores (except subaccounts)
• Maximum 63 characters for URL-related entities:
• Subdomains
• CF orgs and spaces
• Kyma clusters and namespaces

Company Identification

Cloud Foundry Naming Example

Kyma Naming Example

---

SaaS Application Considerations

A SaaS application can only be used once within a subaccount. This necessitates:

• Separate subaccounts per functional area using same SaaS
• Or using CF spaces with HTML5 repository for central Fiori Launchpad

---

Source Documentation:

• https://github.com/SAP-docs/btp-best-practices-guide/blob/main/docs/set-up-and-plan/setting-up-your-account-model-2db81f4.md
• https://github.com/SAP-docs/btp-best-practices-guide/blob/main/docs/set-up-and-plan/account-model-with-directories-and-subaccounts-b5a6b58.md
• https://github.com/SAP-docs/btp-best-practices-guide/blob/main/docs/set-up-and-plan/account-model-with-subaccounts-049d331.md
• https://github.com/SAP-docs/btp-best-practices-guide/blob/main/docs/set-up-and-plan/naming-conventions-for-sap-btp-accounts-5302ea4.md

AI Development Best Practices on SAP BTP

Comprehensive guide for implementing AI solutions on SAP Business Technology Platform using SAP AI Core and related services.

Source Repository: SAP-samples/sap-btp-ai-best-practices Documentation Portal: https://btp-ai-bp.docs.sap/ Project Catalog: AI4U Project Catalog

---

Overview

SAP BTP provides AI capabilities through SAP AI Core, enabling both Generative AI (LLMs, chatbots, RAG) and Narrow AI (classical ML, predictions) implementations.

Requirements:

• SAP Business Technology Platform account
• Access to SAP AI Core service
• Code examples available in: TypeScript, Python, Java, CAP

---

Generative AI Best Practices

1. Secure Access to AI Models

Access generative AI models through SAP AI Core with proper authentication:

# Python example - Secure model access
from gen_ai_hub.proxy.native.openai import OpenAI

client = OpenAI()
response = client.chat.completions.create(
    model="gpt-4",
    messages=[{"role": "user", "content": "Hello, how can you help?"}]
)

// TypeScript example
import { OpenAI } from '@sap-ai-sdk/gen-ai-hub';

const client = new OpenAI();
const response = await client.chat.completions.create({
    model: 'gpt-4',
    messages: [{ role: 'user', content: 'Hello, how can you help?' }]
});

Key Considerations:

• Use SAP AI Core service keys for authentication
• Configure environment variables from .env files
• Never hardcode credentials in application code

2. Prompt Template Patterns

Create effective, reusable prompts:

# Prompt template pattern
SYSTEM_PROMPT = """You are a helpful assistant for {domain}.
Your task is to {task_description}.
Always respond in {language}."""

USER_PROMPT = """
Context: {context}
Question: {user_question}
"""

Best Practices:

• Separate system and user prompts
• Use placeholders for dynamic content
• Include clear task descriptions
• Specify output format expectations

3. Retrieval-Augmented Generation (RAG)

Implement RAG systems for grounding LLM responses with enterprise data:

Architecture:

Documents → Chunking → Embeddings → Vector Store
                                         ↓
User Query → Embedding → Similarity Search → Context
                                                ↓
                         LLM ← Context + Query → Response

Key Components:

• Document chunking strategies
• Vector embeddings (SAP AI Core embedding models)
• Vector database (SAP HANA Cloud Vector Engine)
• Context window management

4. Content Filtering

Implement content safety for AI-generated outputs:

• Configure content filtering policies in SAP AI Core
• Implement input validation before sending to models
• Add output filtering for inappropriate content
• Log and monitor filtered content for analysis

5. PII Data Masking

Protect personally identifiable information:

# Data masking pattern
def mask_pii(text: str) -> str:
    """Mask PII before sending to LLM"""
    # Replace emails, phone numbers, SSNs
    masked = re.sub(r'\b[\w.-]+@[\w.-]+\.\w+\b', '[EMAIL]', text)
    masked = re.sub(r'\b\d{3}[-.]?\d{3}[-.]?\d{4}\b', '[PHONE]', masked)
    return masked

Best Practices:

• Mask PII before sending to external models
• Use SAP Data Privacy Integration where available
• Implement reversible masking for response reconstruction
• Audit PII handling in AI workflows

---

CAP + AI Integration Patterns

Production-tested patterns for integrating LLMs into CAP applications on SAP BTP.

Architecture

Fiori Frontend → CAP Service → SAP Cloud SDK for AI → AI Core (Orchestration) → LLM Provider
                     ↓                                       ↑
              HANA Database                          BTP Service Binding
              (Vector columns)                    (No API keys in code)

The CAP service never holds LLM provider credentials. It authenticates via BTP service binding to AI Core, which routes to the configured provider (Azure OpenAI, AWS Bedrock, etc.). Changing providers requires only an AI Core configuration change, no code modification.

Service Binding (MTA)

resources:
  - name: my-ai-core
    type: org.cloudfoundry.managed-service
    parameters:
      service: aicore
      service-plan: extended  # Required for Generative AI Hub

Dependencies

npm install @sap-ai-sdk/orchestration

CAP Event Handler with AI (TypeScript/JavaScript)

import { OrchestrationClient } from '@sap-ai-sdk/orchestration';
import cds from '@sap/cds';

export default class FeedbackService extends cds.ApplicationService {
  async init() {
    const client = new OrchestrationClient({
      promptTemplating: {
        model: { name: 'gpt-4o' },
        prompt: [
          { role: 'system', content: 'Categorize feedback as JSON: sentiment, category, urgency.' },
          { role: 'user', content: '{{?feedback}}' }
        ]
      }
    });

    this.on('analyzeFeedback', async (req) => {
      const response = await client.chatCompletion({
        placeholderValues: { feedback: req.data.text }
      });
      return response.getContent();
    });

    return super.init();
  }
}

Asynchronous Processing (Critical for Production)

LLM responses can take 30-60 seconds. The BTP load balancer and database connection pool will timeout before the LLM responds. Never call LLMs synchronously in production CAP services.

this.on('analyzeFeedback', async (req) => {
  // 1. Immediately persist with "processing" status
  const entry = await INSERT.into('FeedbackResults').entries({
    originalText: req.data.text,
    status: 'processing'
  });

  // 2. Spawn background job for LLM call
  cds.spawn(() => this.processWithLLM(entry.ID, req.data.text));

  // 3. Return 202 Accepted
  return req.reply(202, { id: entry.ID, status: 'processing' });
});

async processWithLLM(id: string, text: string) {
  try {
    const response = await this.client.chatCompletion({
      placeholderValues: { feedback: text }
    });
    await UPDATE('FeedbackResults', id).set({
      analysisJson: response.getContent(),
      status: 'completed'
    });
  } catch (error) {
    await UPDATE('FeedbackResults', id).set({
      status: 'failed',
      error: error.message
    });
  }
}

HANA Vector Engine for RAG

Define vector columns in CDS for embedding storage:

entity Documents {
  key id       : UUID;
  content      : String(5000);
  embedding    : Vector(1536);  // OpenAI ada-002 dimension
  source       : String;
  createdAt    : Timestamp;
}

Combine with AI Core orchestration grounding module for production RAG pipelines.

Prompt Externalization

Do not hardcode prompts in event handlers. Externalize for maintainability:

entity PromptTemplates {
  key id          : UUID;
  name            : String(100);
  systemPrompt    : LargeString;
  temperature     : Decimal(3,2);
  modifiedAt      : Timestamp;
}

This allows prompt tuning without redeployment — update the database row and the next LLM call picks up the change.

Resilience and Cost Control

Local Development

# Bind to AI Core service instance locally
cds bind -2 <AICORE_INSTANCE> && cds-tsx watch --profile hybrid

Source

These patterns are derived from production deployments documented by CloudDNA and SAP BTP AI best practices. For complete CAP context, see the sap-cap-capire skill. For SDK details, see sap-cloud-sdk-ai skill.

---

Narrow AI Best Practices

Regression Models

Classical ML for predictions (sales forecasting, demand planning):

• Use SAP AI Core for model training and deployment
• Implement proper feature engineering
• Validate models with held-out test data
• Monitor model drift in production

Anomaly Detection

Detect outliers in business data:

Use Cases:

• Financial transaction monitoring
• Quality control in manufacturing
• Log analysis for system health
• Document outlier detection

Approaches:

• Statistical methods (z-score, IQR)
• Machine learning (Isolation Forest, Autoencoders)
• Time-series anomaly detection

---

AI Services Best Practices

SAP Document AI

Extract information from documents:

• Invoice processing
• Purchase order extraction
• Contract analysis
• Form recognition

SAP Translation Hub

Multilingual content translation:

• Configure language pairs
• Handle domain-specific terminology
• Implement async translation for large documents

---

Use Cases Catalog

The repository includes 20+ end-to-end implementations:

---

Quick Start

# Clone the repository
git clone https://github.com/SAP-samples/sap-btp-ai-best-practices.git
cd sap-btp-ai-best-practices

# Navigate to a specific best practice
cd best-practices/generative-ai/access-to-ai-models/python
pip install -r requirements.txt
cp .env.example .env
# Edit .env with your SAP AI Core service key
python main.py

---

Resources

---

License: Apache-2.0 Last Updated: 2025-11-22 Repository: https://github.com/secondsky/sap-skills

SAP BTP Deployment and Delivery - Detailed Reference

Source: https://github.com/SAP-docs/btp-best-practices-guide/tree/main/docs/deploy-and-deliver

---

Deployment Overview

After development, applications are deployed to TEST and PROD environments. The approach depends on organizational needs:

• Simple applications: Manual deployment acceptable
• Enterprise settings: Managed, automated delivery recommended

---

Deployment Methods by Runtime

Cloud Foundry Environment

Key Recommendation: Archive all components into one package as a Multitarget Application (MTA) archive including a deployment descriptor.

Java Applications

Deploy via:

• SAP BTP cockpit
• Cloud Foundry CLI
• Multiple runtime and JVM options available

HTML5 Applications

Deploy via:

• SAP Business Application Studio
• Cloud Foundry CLI
• SAP BTP cockpit

Node.js Applications

Deploy via:

• SAP Business Application Studio
• Cloud Foundry CLI

SAP HANA XSA Applications

Deploy via:

• SAP HANA Deployment Infrastructure (HDI) in Business Application Studio
• Cloud Foundry CLI

Custom Buildpacks

Cloud Foundry supports "Bring Your Own Buildpack" for custom runtime needs.

Neo Environment

Similar deployment options to Cloud Foundry with:

• SAP BTP cockpit
• Neo console client

Kyma Environment

Core Requirement: Package applications in Linux Docker images.

Options:

• Standard Dockerfile
• Cloud Native Buildpacks

Production Setup:

• Use automation tools like SAP Continuous Integration and Delivery
• Deploy with Helm charts
• Sample GitHub repositories available for Java, Node.js, HTML5

---

Delivery Options

Enterprise Delivery Approach

A managed, automated delivery approach is recommended because it:

• Is less error-prone
• Creates repeatable outcomes
• Enables governance
• Provides central control over production propagation

Delivery Options Matrix

---

SAP Continuous Integration and Delivery

Solution Options

SAP CI/CD Service Features

• Pre-configured pipelines for SAP technologies
• Built-in code quality checks
• Automated testing integration
• Direct deployment to SAP BTP

Project "Piper"

• Open-source CI/CD library
• Extensive customization options
• Jenkins-based pipelines
• GitHub: https://github.com/SAP/jenkins-library

---

Transport Management

SAP Cloud Transport Management

Centralizes handling of development content archives across subaccounts and global accounts.

Features:

• MTA file transport
• Application-specific content transport
• Cross-global account transport
• Integration with change management tools

Recommendation: Use for all SAP BTP content regardless of format.

CTS+ (Change and Transport System)

• Operates on-premise within ABAP systems
• Supports SAP BTP artifacts packaged as MTA archives
• Integration with SAP Solution Manager

Direction: SAP Cloud Transport Management is the future-proof choice.

Combined CI/CD and Transport Approach

Developer Commit
       │
       ▼
┌──────────────────┐
│   CI Pipeline    │ (Build, Test, Deploy to Dev)
└────────┬─────────┘
         │
         ▼
┌──────────────────────────────────┐
│  SAP Cloud Transport Management  │
│                                  │
│  Dev ──► Test ──► Production     │
│  (Governance-defined pathways)   │
└──────────────────────────────────┘
         │
         ▼
   Optional Integration
   with SAP Cloud ALM or
   SAP Solution Manager

---

Change Management Integration

SAP Cloud ALM Integration

• Change and deployment management
• Centralized landscape definition
• Access control configuration
• Synchronized transports

SAP Solution Manager Integration

• Minimum version: 7.2 SP10
• Hybrid scenario support (on-premise + cloud)
• Parallel operation with CTS+ and Cloud Transport Management

---

Manual Delivery Methods

For simpler scenarios:

1. Direct IDE Deployment:

• Deploy to multiple subaccounts via cockpit or CLI

2. Solution Export Wizard (Neo):

• Model solutions as MTA files
• Export for transport

3. Git Repository Synchronization:

• For HTML5 applications
• Manual deployment after sync

4. SAP HANA XS Application Lifecycle Management:

• Transport routes between systems

---

Multitarget Application (MTA) Archives

Structure

my-app.mtar
├── mta.yaml (deployment descriptor)
├── app-module-1/
├── app-module-2/
├── db-module/
└── srv-module/

mta.yaml Example

_schema-version: "3.1"
ID: my-mta-app
version: 1.0.0

modules:
  - name: my-srv
    type: nodejs
    path: srv
    provides:
      - name: srv-api
        properties:
          url: ${default-url}
    requires:
      - name: my-db
      - name: my-auth

  - name: my-db-deployer
    type: hdb
    path: db
    requires:
      - name: my-db

resources:
  - name: my-db
    type: com.sap.xs.hdi-container
  - name: my-auth
    type: org.cloudfoundry.managed-service
    parameters:
      service: xsuaa
      service-plan: application

Building MTAs

# Install MTA Build Tool
npm install -g mbt

# Build MTA archive
mbt build

# Result: mta_archives/my-app_1.0.0.mtar

---

Kyma Deployment Details

Docker Image Creation

Standard Dockerfile:

FROM node:18-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
EXPOSE 8080
CMD ["npm", "start"]

Cloud Native Buildpacks:

# Using pack CLI
pack build my-app --builder paketobuildpacks/builder:base

Helm Chart Structure

my-app/
├── Chart.yaml
├── values.yaml
├── templates/
│   ├── deployment.yaml
│   ├── service.yaml
│   ├── ingress.yaml
│   └── configmap.yaml
└── charts/

Deployment Commands

# Deploy with Helm
helm upgrade --install my-app ./my-app \
  --namespace my-namespace \
  --set image.tag=1.0.0

# Or use kubectl directly
kubectl apply -f k8s/

---

CI/CD Pipeline Example

SAP CI/CD Service Configuration

# .pipeline/config.yml
general:
  buildTool: 'mta'

stages:
  Build:
    mtaBuild: true

  Additional Unit Tests:
    npmExecuteScripts:
      - 'test'

  Acceptance:
    cloudFoundryDeploy:
      deployTool: 'mtaDeployPlugin'
      deployType: 'standard'

  Release:
    cloudFoundryDeploy:
      deployTool: 'mtaDeployPlugin'
      deployType: 'standard'

Jenkins Pipeline (Project Piper)

@Library('piper-lib-os') _

node {
    stage('Init') {
        checkout scm
        setupCommonPipelineEnvironment script: this
    }

    stage('Build') {
        mtaBuild script: this
    }

    stage('Deploy') {
        cloudFoundryDeploy script: this
    }
}

---

Transport Landscape Configuration

Defining Transport Routes

┌─────────────────────────────────────────────────────┐
│           SAP Cloud Transport Management            │
├─────────────────────────────────────────────────────┤
│                                                     │
│   Node: Development                                 │
│   ├── Import Queue                                  │
│   └── Forward to: Test                              │
│                                                     │
│   Node: Test                                        │
│   ├── Import Queue                                  │
│   └── Forward to: Production                        │
│                                                     │
│   Node: Production                                  │
│   └── Import Queue                                  │
│                                                     │
└─────────────────────────────────────────────────────┘

Upload to Transport Management

# Using Cloud Transport Management API
curl -X POST "https://[ctms-url]/v2/files/upload" \
  -H "Authorization: Bearer $TOKEN" \
  -F "file=@my-app.mtar"

# Create transport request
curl -X POST "https://[ctms-url]/v2/nodes/[node-id]/transportRequests" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"fileId": "[file-id]", "description": "Deploy version 1.0.0"}'

---

Best Practices Summary

Deployment

1. Use MTA archives for multi-component applications 2. Containerize applications for Kyma with proper Docker images 3. Implement proper health checks and probes 4. Use environment-specific configuration

Delivery

1. Combine CI/CD with Cloud Transport Management 2. Automate testing at every stage 3. Implement proper approvals for production 4. Maintain audit trails for compliance

Governance

1. Define clear transport routes 2. Implement approval workflows 3. Restrict who can deploy to production 4. Track all changes through transport requests

---

Source Documentation:

• https://github.com/SAP-docs/btp-best-practices-guide/blob/main/docs/deploy-and-deliver/deploy-and-deliver-5972cdb.md
• https://github.com/SAP-docs/btp-best-practices-guide/blob/main/docs/deploy-and-deliver/deploying-applications-866ab13.md
• https://github.com/SAP-docs/btp-best-practices-guide/blob/main/docs/deploy-and-deliver/delivering-applications-b39bae3.md

SAP BTP Failover and Resilience - Detailed Reference

Source: https://github.com/SAP-docs/btp-best-practices-guide/tree/main/docs/deploy-and-deliver

---

High Availability Overview

SAP BTP applications can achieve high availability through multi-region deployment with intelligent traffic routing. This eliminates single points of failure and addresses latency concerns for global users.

---

Multi-Region Architecture

Core Concept

                    Custom Domain URL
                           │
                           ▼
                    ┌──────────────┐
                    │ Load Balancer │
                    │ (Health Checks)│
                    └──────┬───────┘
                           │
              ┌────────────┴────────────┐
              ▼                         ▼
    ┌─────────────────┐       ┌─────────────────┐
    │  Region 1       │       │  Region 2       │
    │  (Active)       │       │  (Passive/Active)│
    │                 │       │                 │
    │  Subaccount A   │       │  Subaccount B   │
    │  App Instance   │       │  App Instance   │
    └─────────────────┘       └─────────────────┘

Key Benefits

• Geographic Redundancy: Regional outages don't interrupt service
• Intelligent Routing: Health checks direct traffic to operational instances
• Unified Access: Custom domain remains constant during failovers
• Load Distribution: Traffic balances across regions
• Latency Optimization: Route users to nearest healthy region

---

Failover Scope

Supported Application Types

The basic failover guidance applies to:

• SAPUI5 applications
• HTML5 applications
• Applications without data persistence
• Applications without in-memory caching
• Applications with data stored in on-premise back-end systems

Note: Applications with cloud-based persistence require additional considerations for data synchronization.

---

Four Core Failover Principles

1. Deploy Across Two Data Centers

Configuration: Active/Passive

• Primary data center receives normal traffic
• Secondary data center acts as standby
• Switch to secondary only during primary downtime

Regional Selection Best Practices:

• Choose regions near users and backend systems
• Example: Frankfurt and Amsterdam for European users
• Consider same region for performance
• Review data processing restrictions for cross-region deployment

Legal Consideration: Cross-region deployment may create data processing compliance issues. Review Data Protection and Privacy documentation before proceeding.

2. Keep Applications Synchronized

Synchronization Options:

Manual Synchronization

• Duplicate modifications across both data centers
• Mirror Git repositories
• Allows non-identical applications (reduced functionality in backup)
• Visual differentiation between primary and backup

CI/CD Pipeline Synchronization

# Pipeline deploys to both regions
stages:
  - name: Build
    steps:
      - build_mta

  - name: Deploy Primary
    steps:
      - deploy_to_region_1

  - name: Deploy Secondary
    steps:
      - deploy_to_region_2

• Use Project "Piper" pipelines adapted for multi-deployment
• Parallel deployment to subaccounts in different regions
• Automatic consistency

Solution Export Wizard + Cloud Transport Management

1. Export changes as MTA archive from primary (Neo) 2. Import via Transport Management Service (Cloud Foundry) 3. Deploy to secondary data center

3. Define Failover Detection

Detection Mechanisms:

• Response timeout monitoring (e.g., 25 seconds max)
• HTTP status code checking (5xx errors)
• Health endpoint monitoring

Implementation Options:

• Manual code implementation
• Rule-based solutions (e.g., Akamai ION)
• Load balancer health checks

Detection Behavior:

• Monitor first HTTP request to application URL
• Ignore subsequent requests (prevent single resource failures triggering failover)
• Present HTML down page with failover link when detected

Note: In basic scenarios, "the failover itself is therefore manually performed by the user" via the down page link.

4. Plan for Failback

Active/Active Setup:

• Applications identical in both data centers
• Same functionality everywhere
• Failback automatic with next failover event
• Not mandatory to explicitly return to primary

Active/Passive Setup:

• Applications may differ between data centers
• Reduced functionality in backup acceptable
• Failback to primary is mandatory
• Must restore full functionality

Recommended Failback Approach:

• User-driven failback model
• Visual differentiation reminds users to switch back
• Allow transactions to complete without interruption
• Prioritize completion over automatic recovery speed

---

Multi-Region Reference Use Cases

Available Implementations

Architecture: SAP Build Work Zone + Azure Traffic Manager

User Request
     │
     ▼
Azure Traffic Manager
(Priority-based routing)
     │
     ├──► Primary Region (Priority 1)
     │    └── SAP Build Work Zone Instance
     │
     └──► Secondary Region (Priority 2)
          └── SAP Build Work Zone Instance (standby)

Architecture: CAP + HANA Cloud Multi-Zone

     Application Load Balancer
              │
     ┌────────┴────────┐
     ▼                 ▼
CAP App (AZ1)     CAP App (AZ2)
     │                 │
     └────────┬────────┘
              ▼
    SAP HANA Cloud
    (Multi-zone replication)

---

Data Backup and Resilience

SAP-Managed Backups

Object Store Protection Mechanisms

• Object Versioning: Recover from accidental deletion
• Expiration Rules: Automatic version cleanup
• Deletion Prevention: AWS S3 buckets, Azure containers

Runtime-Specific Backup Strategies

Customer-Managed Backups

Critical: SAP doesn't manage backups of service configurations. You are responsible for backing up your service-specific configurations.

Key Responsibilities:

Actions Required: 1. Identify all SAP BTP services currently in use 2. Review service-specific backup documentation 3. Understand which services lack backup capabilities 4. Implement backup strategies for supported configurations 5. Plan accordingly for services without backup features 6. Ensure business continuity plans include config recovery

Note: If backup information is unavailable for a service, contact SAP support channels.

---

Kyma Cluster Sharing and Isolation

When to Share Clusters

Recommended:

• Small teams with modest resource needs
• Development and testing environments
• Non-critical workloads
• Teams with established trust

Not Recommended:

• Multiple external customers
• Production workloads with strict isolation
• Untrusted tenants

Control Plane Isolation Strategies

Data Plane Isolation Strategies

Sample Network Policy

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-cross-namespace
  namespace: tenant-a
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              name: tenant-a
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              name: tenant-a

---

Disaster Recovery Planning

Recovery Time Objective (RTO)

Depends on:

• Failover detection speed
• Application synchronization lag
• User-driven vs automatic failover

Recovery Point Objective (RPO)

Depends on:

• Synchronization frequency
• Data persistence strategy
• Backup retention periods

DR Checklist

• [ ] Define RTO and RPO requirements
• [ ] Select multi-region architecture
• [ ] Implement application synchronization
• [ ] Configure failover detection
• [ ] Test failover procedures regularly
• [ ] Document failback process
• [ ] Train operations team
• [ ] Establish communication protocols

---

Resilient Application Development

Design Principles

1. Statelessness: Minimize in-memory state 2. Idempotency: Safe to retry operations 3. Circuit Breakers: Graceful degradation 4. Health Endpoints: Enable monitoring 5. Graceful Shutdown: Complete in-flight requests

Health Endpoint Example

app.get('/health', (req, res) => {
  const health = {
    status: 'UP',
    checks: {
      database: checkDatabase(),
      cache: checkCache(),
      externalApi: checkExternalApi()
    }
  };

  const allHealthy = Object.values(health.checks)
    .every(check => check.status === 'UP');

  res.status(allHealthy ? 200 : 503).json(health);
});

---

Source Documentation:

• https://github.com/SAP-docs/btp-best-practices-guide/blob/main/docs/set-up-and-plan/planning-failover-on-sap-btp-8c46464.md
• https://github.com/SAP-docs/btp-best-practices-guide/blob/main/docs/deploy-and-deliver/implementing-failover-df972c5.md
• https://github.com/SAP-docs/btp-best-practices-guide/blob/main/docs/deploy-and-deliver/deploy-your-application-in-two-data-centers-61d08d8.md
• https://github.com/SAP-docs/btp-best-practices-guide/blob/main/docs/deploy-and-deliver/keep-the-two-applications-in-sync-e6d2bdb.md
• https://github.com/SAP-docs/btp-best-practices-guide/blob/main/docs/deploy-and-deliver/define-how-a-failover-is-detected-88b86db.md
• https://github.com/SAP-docs/btp-best-practices-guide/blob/main/docs/deploy-and-deliver/decide-on-the-failback-963f962.md
• https://github.com/SAP-docs/btp-best-practices-guide/blob/main/docs/deploy-and-deliver/multi-region-usecases.md
• https://github.com/SAP-docs/btp-best-practices-guide/blob/main/docs/deploy-and-deliver/data-backups-managed-by-sap-6c1e071.md
• https://github.com/SAP-docs/btp-best-practices-guide/blob/main/docs/set-up-and-plan/sharing-clusters-in-kyma-57ec1ea.md

SAP BTP Governance and Teams - Detailed Reference

Source: https://github.com/SAP-docs/btp-best-practices-guide/tree/main/docs/set-up-and-plan

---

Governance Model Overview

Establishing an appropriate organizational setup and governance model is one of the first and most important steps in the cloud journey.

Benefits of Good Governance

• Easier adoption of agile processes
• Clear responsibilities and ownership
• Streamlined onboarding for new projects
• Consistent security and compliance
• Efficient resource utilization

Preparatory Steps

Before launching development initiatives: 1. Establish an onboarding framework for new projects 2. Create a knowledge transfer system for teams

Governance Model Implementation Areas

Reference: Team Topologies (teamtopologies.com) for organizational design patterns.

---

Team Structure

Required Teams

Platform Engineering Team (Center of Excellence)

Purpose: Manage cloud landscape infrastructure and reduce complexity for development teams.

Core Responsibilities:

• Account operations and management
• Build infrastructure setup
• Governance and compliance guidelines
• Security framework implementation
• Enable developers with reduced cognitive load
• Operate and ensure stable, secure cloud landscape

Extended CoE Functions:

• Drive cloud adoption and migration organization-wide
• Provide thought leadership and roadblock resolution guidance
• Identify, evaluate, and implement SAP BTP use cases
• Can include enabling teams composed of specialists

Does NOT Handle:

• Individual application lifecycles
• Application-specific development
• Application-specific operations

Composition:

• Skilled technology experts
• Cloud architects
• Security specialists
• Infrastructure engineers
• May include specialized sub-teams

Cloud Development Teams

Purpose: Develop and operate applications on SAP BTP.

Approach: DevOps model - same team both develops AND operates applications.

Responsibilities:

• Application development
• Application deployment
• Application monitoring
• Regular maintenance
• Post-launch support
• UI component compatibility verification (every 6 months)

Key Principle: Avoid traditional Build-Run separation where different teams handle development versus operations.

---

Essential Documentation

Three Core Documents

Onboarding Document Contents

Every new application should document:

Security Document Contents

Requires security expert approval before development begins.

Services Catalog Contents

Platform Engineering Team provides templated services:

• Destination management
• Build configuration
• Application restart procedures
• Access provisioning
• Database schema creation
• CI/CD pipeline templates
• Monitoring setup

Automation Options:

• SAP BTP APIs
• btp CLI
• SAP BTP Setup Automator

---

Knowledge Transfer Process

Key Practices

1. Document and Share: Platform Engineering Team documents and shares knowledge with current and incoming staff

2. Training Sessions: "Set up training and enablement sessions to get everyone on board"

3. Communication Channels: Create dedicated channels (e.g., SAP Build Work Zone) for:

• Lessons learned
• Guidance and recommendations
• Best practice sharing
• Q&A support

Knowledge Areas

• Platform architecture and capabilities
• Account model and structure
• Security requirements and procedures
• Development standards
• Deployment processes
• Operations procedures

---

Onboarding Process for Projects

Project Enrollment Steps

1. Submit Onboarding Document: Complete all required fields 2. Security Review: Security document approval 3. Resource Allocation: Assign subaccounts, quotas, entitlements 4. Access Provisioning: Set up team access rights 5. Integration Setup: Configure Cloud Connector, destinations 6. CI/CD Setup: Establish deployment pipelines 7. Monitoring Setup: Configure alerting and dashboards

Self-Service vs. Managed

---

Account Administration Tools

Available Options

btp CLI Overview

Alternative to cockpit for users who:

• Prefer terminal work
• Want to automate operations using scripts

Handles:

• Global account management
• Directory management
• Subaccount management

Note: Environment-specific tools needed after environment creation:

• cf CLI (Cloud Foundry)
• Kyma CLI
• kubectl (Kubernetes)

Terraform Provider

Purpose: Automate infrastructure provisioning using code (IaC).

Current Status: Available for non-productive environments; SAP developing for production use.

Repository: HashiCorp registry + SAP GitHub samples

Example:

resource "btp_subaccount" "my_subaccount" {
  name      = "my-dev-subaccount"
  subdomain = "my-company-dev"
  region    = "eu10"
}

resource "btp_subaccount_entitlement" "hana_cloud" {
  subaccount_id = btp_subaccount.my_subaccount.id
  service_name  = "hana-cloud"
  plan_name     = "hana"
}

---

Shared Responsibility Model

SAP Manages

Customer Manages

Additional Resources

• SAP BTP Security Recommendations
• Operating Model documentation

---

Cost Management Governance

Commercial Model Selection

Contract Strategies

1. Consolidation: Combine subscriptions into one global account (reduces TCO) 2. Hybrid Accounts: Mix subscription and consumption-based 3. Separation: Multiple consumption contracts require separate global accounts

Note: Consumption credits non-transferable between global accounts.

Governance Practices

1. Minimal Entitlements: Provide only required set to prevent overage 2. Quota Management: Set appropriate limits per subaccount 3. Monthly Monitoring: Review costs and usage in cockpit 4. Label Usage: Enable filtering and cost allocation 5. Automated Alerts: Set up usage threshold notifications

---

Checklist: Account Model Setup

Prerequisites

• [ ] Review SAP Cloud Identity Services onboarding guide
• [ ] Assess organizational needs for account model selection
• [ ] Test hierarchy with pilot project managers
• [ ] Familiarize teams with administration tools

Ownership Structure

Standards to Define

• [ ] Directory creation template and process
• [ ] Naming conventions
• [ ] Labels and values for reporting
• [ ] Quota limitation rules
• [ ] Entitlement distribution rules

Directory Template Required Fields

• Name (following naming guidelines)
• Minimum two owners
• Description of developer audience
• Expected applications
• Cost center allocation
• Enrollment procedures

---

Staged Development Environment

Standard Three-Subaccount Model

Flexibility Options

• Combine development and testing
• Create additional subaccounts for large backends
• Maintain separate subaccounts for different projects

Reasons for Separate Subaccounts

1. Isolate different projects or scenarios 2. Separate team workflows 3. Control application access and administration 4. Share databases across similar projects 5. Host centralized shared services

Important Considerations

---

Development Lifecycle

Phases

1. Explore: Identify business opportunity, set up team roles 2. Discover: Identify use cases, understand technology 3. Design: User experience design, domain-driven design 4. Deliver: Set up landscape, develop application 5. Run and Scale: Gather feedback, optimize, operate

Programming Models

SAP Cloud Application Programming Model (CAP):

• Framework for enterprise-grade services
• Supports Java, JavaScript, TypeScript
• Domain-driven design approach

ABAP Cloud:

• Modern ABAP for cloud
• RAP (RESTful ABAP Programming Model)
• Extensions for ABAP-based products

---

Source Documentation:

• https://github.com/SAP-docs/btp-best-practices-guide/blob/main/docs/set-up-and-plan/creating-a-governance-model-bf0ce2c.md
• https://github.com/SAP-docs/btp-best-practices-guide/blob/main/docs/set-up-and-plan/building-teams-fdeddf2.md
• https://github.com/SAP-docs/btp-best-practices-guide/blob/main/docs/set-up-and-plan/creating-a-knowledge-transfer-process-630c14c.md
• https://github.com/SAP-docs/btp-best-practices-guide/blob/main/docs/set-up-and-plan/creating-an-onboarding-process-for-development-projects-4bd29a8.md
• https://github.com/SAP-docs/btp-best-practices-guide/blob/main/docs/set-up-and-plan/tools-for-account-administration-6bdb3a7.md
• https://github.com/SAP-docs/btp-best-practices-guide/blob/main/docs/shared-responsibility/shared-responsibility-model-between-you-and-sap-898509d.md

SAP BTP Operations and Monitoring - Detailed Reference

Source: https://github.com/SAP-docs/btp-best-practices-guide/tree/main/docs/go-live-and-monitor

---

Go-Live Process

Prerequisites

1. Complete testing and compliance verification 2. Establish staging environment structure 3. Deploy application to production environment 4. Configure user provisioning and authorization

Go-Live Timing Best Practices

• Establish specific timeframes for go-live activities
• Restrict deployments during critical periods (e.g., quarter-end)
• Allow exceptions only for emergencies
• Document change freeze windows

User Enablement

Recommendation: Embed applications in SAP Fiori Launchpad via SAP BTP Portal before go-live.

Benefits:

• Improved usability
• Consistent user experience
• Central application access point
• Role-based app visibility

---

Authentication and Authorization Post Go-Live

Business User Provisioning

Users must be provisioned through:

• SAP ID Service
• External identity providers (recommended: SAP Cloud Identity Services)

Authorization Configuration

Administrators can:

• Create roles based on application requirements
• Build role collections grouping related roles
• Assign collections to business users and user groups

Role Collection Example

Role Collection: HR_MANAGER
├── Role: EmployeeViewer (from app-hr)
├── Role: TeamManager (from app-hr)
└── Role: ReportAccess (from app-reporting)

---

Content Delivery Network (CDN)

Use Case

For geographically distributed users, CDN improves:

• Response times
• Load distribution
• Static content delivery

CDN Best Practices

Cache-Control Header Example

# Static assets - long cache
Cache-Control: public, max-age=31536000

# HTML - revalidate
Cache-Control: no-cache

# API responses - no cache
Cache-Control: no-store, must-revalidate

---

SAP Cloud ALM

Overview

SAP Cloud ALM is included in SAP Cloud Service subscriptions containing Enterprise Support. It provides unified monitoring for:

• SAP BTP-based applications
• Custom applications
• Hybrid landscapes

Monitoring Capabilities

Integration with SAP BTP

SAP BTP Applications
        │
        ▼
   Data Collection
        │
        ▼
  ┌─────────────────┐
  │   SAP Cloud ALM │
  │                 │
  │ ┌─────────────┐ │
  │ │ Dashboards  │ │
  │ └─────────────┘ │
  │ ┌─────────────┐ │
  │ │ Alerts      │ │
  │ └─────────────┘ │
  │ ┌─────────────┐ │
  │ │ Analytics   │ │
  │ └─────────────┘ │
  └─────────────────┘

---

Local SAP BTP Monitoring Tools

SAP Job Scheduling Service

Purpose: Schedule and manage recurring jobs across runtimes.

Features:

• Runtime-agnostic (CF, Kyma)
• Cron-based scheduling
• Job monitoring and history
• Retry policies

Example Job Definition:

{
  "name": "daily-cleanup",
  "description": "Daily data cleanup job",
  "action": "https://my-app.cfapps.region.hana.ondemand.com/cleanup",
  "active": true,
  "httpMethod": "POST",
  "schedules": [
    {
      "cron": "0 0 2 * * *",
      "description": "Run at 2 AM daily",
      "active": true
    }
  ]
}

SAP Cloud Logging

Purpose: Centralized observability for logs, metrics, and traces.

Supported Runtimes:

• Cloud Foundry
• Kyma
• Kubernetes

Features:

• Log aggregation
• Metrics collection
• Distributed tracing
• Alerting integration

Neo Environment Monitoring

For Neo applications (Java, SAP HANA XS, HTML5):

• Cockpit-based monitoring
• Application metrics
• Resource utilization
• Error tracking

---

Platform Availability Monitoring

SAP Trust Center

Access platform status at: https://www.sap.com/about/trust-center/cloud-service-status.html

Features:

• Region-specific status
• Service availability
• Planned maintenance windows
• Incident history

Cloud System Notification Subscriptions

Subscribe to notifications for:

• Planned maintenance
• Incidents
• Status updates
• Region-specific events

---

Alerting

SAP Alert Notification Service

Purpose: Instant notifications across multiple delivery channels.

Delivery Channels:

• Email
• Slack/Microsoft Teams
• Ticketing systems (ServiceNow, JIRA)
• SAP Cloud ALM
• Custom webhooks

Alert Configuration Example

{
  "name": "high-error-rate",
  "description": "Alert on high error rate",
  "conditions": {
    "eventType": "error",
    "severity": "ERROR",
    "threshold": 10,
    "timeWindow": "5m"
  },
  "actions": [
    {
      "type": "EMAIL",
      "recipients": ["ops-team@company.com"]
    },
    {
      "type": "SLACK",
      "webhookUrl": "https://hooks.slack.com/..."
    }
  ]
}

Alert Best Practices

1. Define Alert Severity Levels: Critical, Warning, Info 2. Set Appropriate Thresholds: Avoid alert fatigue 3. Implement Escalation: Time-based escalation paths 4. Document Runbooks: Response procedures for each alert type 5. Regular Review: Tune alerts based on false positive rates

---

Operations Automation

SAP Automation Pilot

Purpose: Low-code/no-code automation for operational tasks.

Capabilities:

• Pre-built automation commands
• Custom command creation
• Manual or triggered execution
• Integration with monitoring services

Use Cases:

• Application restart procedures
• Scaling operations
• Backup triggers
• Incident response automation
• Resource cleanup

Automation Example: Application Restart

name: RestartApplication
description: Restart CF application on health check failure
trigger:
  type: ALERT
  source: SAP_ALERT_NOTIFICATION
  conditions:
    eventType: HEALTH_CHECK_FAILED
steps:
  - name: StopApplication
    command: cf.StopApplication
    parameters:
      applicationName: ${event.applicationName}
      orgName: ${event.orgName}
      spaceName: ${event.spaceName}
  - name: Wait
    command: Sleep
    parameters:
      duration: 30s
  - name: StartApplication
    command: cf.StartApplication
    parameters:
      applicationName: ${event.applicationName}
      orgName: ${event.orgName}
      spaceName: ${event.spaceName}

---

Integration and Testing

Integration Tests

Definition: Verify all building blocks work together, meet requirements, and fulfill business cases.

Timing: After landscape integration, part of CI/CD pipelines

Distinction from Unit Tests: Integration tests verify complete system interplay across multiple components.

SAPUI5 Integration Testing

OPA5 (One Page Acceptance Tests):

• API for SAPUI5 controls
• Test user interactions
• Test navigation
• Test data binding
• Manages asynchronicity

Example OPA5 Test:

opaTest("Should navigate to detail page", function(Given, When, Then) {
  Given.iStartMyApp();
  When.onTheMainPage.iPressOnTheFirstItem();
  Then.onTheDetailPage.iShouldSeeTheDetailPage();
  Then.iTeardownMyApp();
});

Application Integration Options

---

Cost Management

Monitoring Costs

1. Monthly Review: Check Costs and Usage in BTP cockpit 2. Service Analysis: Identify top cost contributors 3. Trend Analysis: Track usage patterns 4. Label Filtering: Use labels for custom cost views

Billing Validation

• Access Billing section in cockpit
• Current month shows estimations
• Drill into costs by subaccount and service
• Export data for internal accounting

Cost Distribution Methods

Automated Cost Alerting

Combine:

• Usage Data Management service
• Alert Notification service

To receive alerts when:

• Approaching quota limits
• Unusual consumption patterns
• Budget thresholds exceeded

---

Maintenance and Improvement

Ongoing Maintenance Tasks

1. Regular Testing: Prevent issues from library/platform updates 2. Compliance Verification: Ongoing security and policy checks 3. Bug Fixes: Focus on user experience quality 4. User Feedback: Incorporate improvement suggestions 5. Automated Alerting: Via SAP Alert Notification Service 6. Task Automation: Using SAP Automation Pilot

Update Strategies

Staying Current

• Review SAP Release Notes regularly
• Monitor SAP Community for updates
• Subscribe to product notifications
• Plan for major version upgrades

---

Application Retirement

Decommissioning Checklist

1. [ ] Notify users of retirement timeline 2. [ ] Export required data 3. [ ] Undeploy the application 4. [ ] Delete related service instances 5. [ ] Remove destinations 6. [ ] Remove role collections 7. [ ] Clean up platform content 8. [ ] Meet data retention obligations 9. [ ] Document decommissioning 10. [ ] Archive configuration for reference

Neo to Multi-Cloud Migration

SAP recommends migrating from Neo to multi-cloud foundation:

• Closer integration with AWS, GCP, Azure
• Modern runtime options
• Future-proof architecture

---

Source Documentation:

• https://github.com/SAP-docs/btp-best-practices-guide/blob/main/docs/go-live-and-monitor/go-live-and-operate-b0ab4fb.md
• https://github.com/SAP-docs/btp-best-practices-guide/blob/main/docs/integrate-and-test/integrate-and-test-84ddc25.md
• https://github.com/SAP-docs/btp-best-practices-guide/blob/main/docs/improve-and-retire/improve-and-retire-89ffeab.md
• https://github.com/SAP-docs/btp-best-practices-guide/blob/main/docs/set-up-and-plan/managing-cost-c615301.md

SAP BTP Security and Authentication - Detailed Reference

Source: https://github.com/SAP-docs/btp-best-practices-guide/tree/main/docs/set-up-and-plan

---

Security Fundamentals

Applications on SAP BTP are exposed to the Internet and must fulfill the highest security requirements to prevent unauthorized access.

Network Security

The SAP BTP landscape runs in an isolated network protected by:

• Firewalls
• DMZ (Demilitarized Zone)
• Communication proxies for all inbound/outbound traffic
• Transport Layer Security (TLS) encryption for all user connections

---

User Types

Platform Users

Developers, administrators, and operators who:

• Deploy applications
• Administer accounts and environments
• Troubleshoot platform issues

Permissions managed through: Membership assignments at global account, directory, subaccount, and environment levels.

Business Users

End users of deployed applications and SaaS services who require:

• Authentication configuration
• Authorization controls
• Role assignments

---

Identity Provider Architecture

Recommended Setup

Always use SAP Cloud Identity Services - Identity Authentication for SAP BTP.

┌─────────────────┐      ┌──────────────────────┐      ┌─────────────┐
│ Corporate IdP   │ ──── │ Identity             │ ──── │ SAP BTP     │
│ (ADFS, Okta,   │      │ Authentication       │      │             │
│  Azure AD)      │      │ (Proxy Mode)         │      │             │
└─────────────────┘      └──────────────────────┘      └─────────────┘

Benefits of Proxy Mode:

• Single integration point for multiple corporate IdPs
• Centralized security policies
• Required for certain user types and applications
• Consistent authentication experience

Default Identity Providers

Trust Configuration Levels

Critical: Maintain backup administrators in default provider OR alternative custom provider for recovery scenarios.

---

SAP Cloud Identity Services Onboarding

Why Onboard?

The default identity provider doesn't support:

• Custom security policies
• Multifactor authentication
• SCIM APIs for user provisioning

Tenant Options

Organizations receive both productive and test tenants:

Option 1: Test tenant for dev/test, productive for all Option 2: Test tenant for dev/test only, productive for production

Onboarding Procedure

Step 1: Administrator Setup

• Add multiple administrators (coverage across time zones)
• Ensure backup during absences

Step 2: Security Hardening

• Implement MFA for administrator accounts
• "Administrators have critical access to the system. Set a higher security standard."

Step 3: Monitoring Configuration

• Establish system notifications
• Configure security alerts

Step 4: Corporate Integration

• Configure Identity Authentication as proxy
• Connect to corporate identity provider(s)

---

Authorization Methods

Comparison Table

Recommendations

• Production with many users: Use provisioning or federation
• Feasible scenarios: Prefer provisioning
• Simple setups: Federation acceptable
• Testing only: Manual assignment okay

---

Identity Lifecycle Management

Central Identity Management

The persistency layer of SAP Cloud Identity Services is the Identity Directory.

Process: 1. Corporate identity system → Identity Provisioning → SAP Cloud Identity Services 2. Identity Directory stores user data 3. Identity Provisioning synchronizes to SAP BTP applications

Global User ID

Use universally unique identifiers rather than changeable attributes:

Avoid: Email addresses (can change) Use: Generated UUID or corporate employee ID

Authentication Requirements

Implementation Options

1. Manual: Create users via BTP cockpit, CLI, or APIs 2. Automatic: Create after successful IdP authentication 3. Centralized: Manage through SAP Cloud Identity Services

---

Platform User Access Rights

Team-Based Access Distribution

Environment-Specific Roles

Cloud Foundry

Security Note: Space Developer provides broad access; restrict in production.

ABAP Environment

Requires both:

• CF roles: Org Manager, Space Manager, Space Developer
• ABAP business roles: SAP_BR_ADMINISTRATOR, SAP_BR_DEVELOPER

Kyma

Uses Kubernetes RBAC:

• Start with simple role concept separating developers and operators
• Refine as needed
• See Kyma RBAC reference for details

Neo

• Administrators assign predefined platform roles
• Custom roles can be configured

Sensitive Production Access

For scenarios where even Platform Engineering cannot access data:

1. Automate tasks requiring developer access 2. Integrate into CI/CD pipelines using technical users 3. Temporary role assignment for firefighter situations 4. Special user accounts with controlled credential distribution 5. Maintain audit trails of all access usage

---

Destination Authentication Methods

Complete Method Reference

Recommendations

For SAP Systems: PrincipalPropagation For Third-Party: OAuth2SAMLBearerAssertion For Token Exchange: OAuth2JWTBearer (preferred over OAuth2UserTokenExchange)

Avoid in Production: BasicAuthentication, OAuth2Password

---

Identity Propagation

Cloud Foundry Environment

Decision Tree: 1. SAP system on-premise? → Use PrincipalPropagation 2. Third-party system? → Use OAuth2SAMLBearerAssertion 3. Same tenant token exchange? → Use OAuth2JWTBearer

Neo Environment

Follow similar principles:

• PrincipalPropagation for SAP systems
• OAuth2SAMLBearerAssertion for third-party

---

Kyma RBAC Details

Recommended Setup Goals

1. Separate operators from development teams 2. Isolate day-to-day accounts from administrative accounts 3. Use dedicated namespaces per service, project, or team 4. Leverage common-resource-viewer ClusterRole for read access

Kubernetes Impersonation Strategy

Rather than granting powerful roles directly, use Kubernetes User Impersonation:

• Subjects (users, groups, service accounts) assume temporary identities
• "Virtual users" (vUsers) needn't exist in the system
• Provides just-in-time privilege escalation

Role Configurations

Operators (All Environments):

• Default: View-only access
• Administrative tasks: Impersonate cluster-admin virtual user

Developers (Dev/Test Clusters):

• Full namespace access via admin ClusterRole binding

Developers (Production Clusters):

• Read-only namespace access via cluster-viewer ClusterRole
• Administrative tasks: Impersonate application-specific virtual users

Sample Manifest: Operator Impersonation

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-admin-impersonator
rules:
- apiGroups: [""]
  resources: ["users"]
  verbs: ["impersonate"]
  resourceNames: ["cluster-admin"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: operators-can-impersonate-admin
subjects:
- kind: Group
  name: operators
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: cluster-admin-impersonator
  apiGroup: rbac.authorization.k8s.io

---

Connectivity and Remote Systems

Destination Benefits

Using destinations provides:

• Separation of application code from configuration
• Easier updates without code changes
• Secure credential and certificate storage
• Runtime resolution of connection details

Destination Creation Levels

Security: Limit access authorizations to minimum necessary.

Cloud Connector

Lightweight on-premise agent establishing secure tunnel:

Capabilities:

• No inbound firewall ports required
• Fine-grained access control per exposed system
• RFC and HTTP protocol support
• Principal propagation for user identity forwarding
• Configuration via SAP BTP cockpit

Note: Each subaccount requires separate Cloud Connector integration setup.

---

mTLS Certificate Extraction

Steps to Extract X.509 Certificates

1. Locate Service Key: Navigate to service instance in BTP cockpit 2. Find Attributes: Look for certificate and key attributes (verify credential-type: x509) 3. Extract Values: Copy to separate text files (avoid \n characters) 4. Save as PEM:

• my-private-key.pem
• my-certificate.pem

5. Combine: Create my-keypair.pem with private key first, then certificate

PEM File Structure

-----BEGIN RSA PRIVATE KEY-----
[Base64 encoded private key]
-----END RSA PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
[Base64 encoded certificate]
-----END CERTIFICATE-----

Note: Converting to .cer, .jks, .p12 requires third-party tools.

---

Data Protection and Privacy

Key Principles

• Compliance should be integrated early in development, not as an afterthought
• Simply using SAP BTP doesn't make applications compliant
• SAP provides security features; you must implement them properly
• Consult legal experts for specific requirements

Important Disclaimer: "SAP does not provide legal advice in any form." Compliance requires case-by-case decisions based on your specific system landscape and applicable laws.

Important Considerations

• Compliance involves multiple systems and products
• User deletion requests may require coordinated removal across platforms
• Tailor decisions to your system environment and legal framework
• SAP Discovery Center provides EU Access service information

SAP's Role vs Your Responsibility

---

Source Documentation:

• https://github.com/SAP-docs/btp-best-practices-guide/blob/main/docs/set-up-and-plan/security-concepts-951d36c.md
• https://github.com/SAP-docs/btp-best-practices-guide/blob/main/docs/set-up-and-plan/setting-up-authentication-1dbce9c.md
• https://github.com/SAP-docs/btp-best-practices-guide/blob/main/docs/set-up-and-plan/setting-up-authorization-cb9f0ac.md
• https://github.com/SAP-docs/btp-best-practices-guide/blob/main/docs/set-up-and-plan/setting-up-identity-lifecycle-2c30208.md
• https://github.com/SAP-docs/btp-best-practices-guide/blob/main/docs/set-up-and-plan/role-based-access-control-rbac-in-kyma-bb31080.md
• https://github.com/SAP-docs/btp-best-practices-guide/blob/main/docs/set-up-and-plan/destination-authentication-methods-765423d.md