zhongwei/gh-secondsky-sap-skills-skills-sap-btp-best-practices
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Initial commit

Browse Source
This commit is contained in:
Zhongwei Li
2025-11-30 08:54:47 +08:00
commit bd301d195d
12 changed files with 3935 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
.claude-plugin/plugin.json Normal file
View File

@@ -0,0 +1,12 @@
{
"name": "sap-btp-best-practices",
"description": "Comprehensive BTP best practices for enterprise cloud architecture, account management, security, deployment, and operations. Covers account hierarchies, Cloud Foundry, Kyma, governance, and CI/CD.",
"version": "1.1.2",
"author": {
"name": "Zhongwei Li",
"email": "zhongweili@tubi.tv"
},
"skills": [
"./"
]
}

3
README.md Normal file
View File

@@ -0,0 +1,3 @@
# sap-btp-best-practices
Comprehensive BTP best practices for enterprise cloud architecture, account management, security, deployment, and operations. Covers account hierarchies, Cloud Foundry, Kyma, governance, and CI/CD.

447
SKILL.md Normal file
View File

@@ -0,0 +1,447 @@
---
name: sap-btp-best-practices
description: |
Production-ready SAP BTP best practices for enterprise architecture, account management, security, and operations. Use when planning BTP implementations, setting up account hierarchies, configuring environments, implementing authentication, designing CI/CD pipelines, establishing governance, building Platform Engineering teams, implementing failover strategies, or managing application lifecycle on SAP BTP.
Keywords: SAP BTP, account hierarchy, global account, directory, subaccount, Cloud Foundry, Kyma, ABAP, SAP Identity Authentication, CI/CD, governance, Platform Engineering, failover, multi-region, SAP BTP best practices
license: GPL-3.0
metadata:
version: "1.3.0"
last_verified: "2025-11-27"
---
# 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-fiori-tools**: Use for UI deployment strategies and frontend application guidelines
Production-ready SAP BTP implementation guidance based on official SAP documentation.
**Quick Links**:
- **Official Guide**: [https://github.com/SAP-docs/btp-best-practices-guide](https://github.com/SAP-docs/btp-best-practices-guide)
- **SAP Help Portal**: [https://help.sap.com/docs/btp/btp-administrators-guide](https://help.sap.com/docs/btp/btp-administrators-guide)
---
## Table of Contents
1. [Platform Fundamentals](#platform-fundamentals)
2. [Account Model Setup](#account-model-setup)
3. [Security and Authentication](#security-and-authentication)
4. [Connectivity](#connectivity)
5. [Governance and Teams](#governance-and-teams)
6. [Development](#development)
7. [AI Development](#ai-development)
8. [Deployment and Delivery](#deployment-and-delivery)
9. [High Availability and Failover](#high-availability-and-failover)
10. [Operations and Monitoring](#operations-and-monitoring)
11. [Cost Management](#cost-management)
12. [Bundled Resources](#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
| Environment | Use Case | Key Features |
|-------------|----------|--------------|
| **Cloud Foundry** | Polyglot apps | Multiple buildpacks, spaces |
| **Kyma** | Cloud-native K8s | Open-source, namespaces |
| **ABAP** | ABAP extensions | RAP, cloud-ready ABAP |
| **Neo** | Legacy | **Migrate away** - HTML5, Java, HANA XS |
### 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
| Entity | Convention | Example |
|--------|------------|---------|
| Subaccount | Natural language | "HR Development" |
| Subdomain | Lowercase, hyphens | `hr-dev-acme` |
| CF Org | Company prefix | `acme-hr-dev` |
| CF Space | Consistent across stages | `hr-recruiting` |
**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
| Method | Best For | Notes |
|--------|----------|-------|
| **Provisioning** | Production, many users | Centralized roles, automated offboarding |
| **Federation** | Simple scenarios | Real-time sync, but doesn't scale well |
| **Manual** | Testing only | Quick setup, not production-ready |
### 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](https://github.com/SAP-samples/sap-btp-ai-best-practices)
- Documentation: [https://btp-ai-bp.docs.sap/](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.
**See**: `references/ai-development-best-practices.md` for patterns and examples
---
## 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
| Tool | Use Case |
|------|----------|
| **SAP BTP Cockpit** | GUI for all admin tasks |
| **btp CLI** | Terminal/automation scripting |
| **REST APIs** | Programmatic administration |
| **Terraform Provider** | Infrastructure as Code |
| **SAP Automation Pilot** | Low-code/no-code automation |
---
## 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**: 2025-11-27
**Review Progress**: See SAP_SKILLS_REVIEW_PROGRESS.md
**Next Review**: 2026-02-27 (quarterly)

77
plugin.lock.json Normal file
View File

@@ -0,0 +1,77 @@
{
"$schema": "internal://schemas/plugin.lock.v1.json",
"pluginId": "gh:secondsky/sap-skills:skills/sap-btp-best-practices",
"normalized": {
"repo": null,
"ref": "refs/tags/v20251128.0",
"commit": "31dbeff5e441adef9b0ffecc6e439f8703d86d90",
"treeHash": "cddec86a3dafa31fd59a68bb4e6fedfd7dae56d9f1109f466173e48b586a1a12",
"generatedAt": "2025-11-28T10:28:11.118149Z",
"toolVersion": "publish_plugins.py@0.2.0"
},
"origin": {
"remote": "git@github.com:zhongweili/42plugin-data.git",
"branch": "master",
"commit": "aa1497ed0949fd50e99e70d6324a29c5b34f9390",
"repoRoot": "/Users/zhongweili/projects/openmind/42plugin-data"
},
"manifest": {
"name": "sap-btp-best-practices",
"description": "Comprehensive BTP best practices for enterprise cloud architecture, account management, security, deployment, and operations. Covers account hierarchies, Cloud Foundry, Kyma, governance, and CI/CD.",
"version": "1.1.2"
},
"content": {
"files": [
{
"path": "README.md",
"sha256": "7ee17acaecf1a80bf022ad1d14a94415750cb730fcbd12e8712c7c2738416970"
},
{
"path": "SKILL.md",
"sha256": "95014da69b9fd7f280b4844c5bd4c0f851055618e692c86465991475bb62f655"
},
{
"path": "references/ai-development-best-practices.md",
"sha256": "f7d8d2eda8438abcc31387fedffffdfff1d129bc5355712485d93f50659709bc"
},
{
"path": "references/operations-and-monitoring.md",
"sha256": "40e6ab4b80eaf578df6d8d001339c02df09e525b8e7b84bb6c250ad685c719e9"
},
{
"path": "references/security-and-authentication.md",
"sha256": "900cdc7ffa1d8d765e45b6979f216a80231444ff8ee5bc6c7d4342f5054bf249"
},
{
"path": "references/governance-and-teams.md",
"sha256": "510e9d2c6a8ab17573a0a857650f8164c94e6ae65c60bfa02581c9cd67559f9e"
},
{
"path": "references/failover-and-resilience.md",
"sha256": "ddc8f84c7a7ae5bdc28242064cd2c94dcd8c754692f357c32cf290c12de2540c"
},
{
"path": "references/templates-and-examples.md",
"sha256": "331b6efdd8dfbc2b0dc1c6435cbfe7b3e3bdf784798720a121d414cdb33c7914"
},
{
"path": "references/deployment-and-delivery.md",
"sha256": "636eb31501814ccf8da9137833f3051cedbc630625aefeb5fe6d76d6377357e9"
},
{
"path": "references/account-models.md",
"sha256": "12cffe129541e10193f9f709dadc4bfe5685f015000f7f0749ebfc9a22773673"
},
{
"path": ".claude-plugin/plugin.json",
"sha256": "02137a152ec1572f384a86e5ecc2586e809a147938668b0e90a60e0fca765351"
}
],
"dirSha256": "cddec86a3dafa31fd59a68bb4e6fedfd7dae56d9f1109f466173e48b586a1a12"
},
"security": {
"scannedAt": null,
"scannerVersion": null,
"flags": []
}
}

366
references/account-models.md Normal file
View File

@@ -0,0 +1,366 @@
# SAP BTP Account Models - Detailed Reference
**Source**: [https://github.com/SAP-docs/btp-best-practices-guide/tree/main/docs/set-up-and-plan](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
| Feature | Subaccount Level | Space Level |
|---------|------------------|-------------|
| Business user groups | Yes | No |
| Cloud Connector tunnels | Yes | No |
| Roles and trust settings | Yes | No |
| Quota assignment | Yes (mandatory) | Yes (optional) |
### 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
| Function | Subaccount | Namespace |
|----------|-----------|-----------|
| User group configuration | Yes | Yes |
| Cloud Connector tunnel | Yes | No |
| Roles/trust setup | Yes | Yes |
| Resource quotas | Yes (mandatory) | Limited |
| Cost monitoring | Yes | No |
---
## 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
| Level | Owner |
|-------|-------|
| Global Account | Platform Engineering Team/CoE |
| Directories | Designated owners with role collections |
| Subaccounts | Designated owners with role collections |
| Spaces/Namespaces | Development units |
### 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
| Entity | Include Company Name? |
|--------|----------------------|
| Subaccount name | No |
| Subdomain | Yes |
| CF Org | Yes |
| Directory | Depends on use case |
### Cloud Foundry Naming Example
| Entity | Dev | Test | Prod |
|--------|-----|------|------|
| Subaccount | HR Development | HR Test | HR Production |
| Subdomain | `acme-hr-dev` | `acme-hr-test` | `acme-hr-prod` |
| CF Org | `acme-hr-dev` | `acme-hr-test` | `acme-hr-prod` |
| Space | `recruiting` | `recruiting` | `recruiting` |
### Kyma Naming Example
| Entity | Dev/Test | Prod |
|--------|----------|------|
| Subaccount | Platform Dev Test | Platform Production |
| Subdomain | `acme-platform-devtest` | `acme-platform-prod` |
| Cluster | `acme-platform-devtest` | `acme-platform-prod` |
| Namespace | `hr-dev`, `hr-test` | `hr` |
---
## 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/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-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/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](https://github.com/SAP-docs/btp-best-practices-guide/blob/main/docs/set-up-and-plan/naming-conventions-for-sap-btp-accounts-5302ea4.md)

234
references/ai-development-best-practices.md Normal file
View File

@@ -0,0 +1,234 @@
# 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](https://github.com/SAP-samples/sap-btp-ai-best-practices)
**Documentation Portal**: [https://btp-ai-bp.docs.sap/](https://btp-ai-bp.docs.sap/)
**Project Catalog**: [AI4U Project Catalog](https://ai4u-website.cfapps.eu10-004.hana.ondemand.com/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
# 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
// 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:
```python
# 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:
```python
# 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
---
## 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:
| Category | Use Case | Description |
|----------|----------|-------------|
| **Chatbots & Agents** | agentic-chatbot | Multi-tool AI agent implementation |
| | email-agent | Automated email processing and response |
| | post-sales-chatbot | Customer support automation |
| **Document Processing** | ai-pdf-information-extraction | Extract data from PDF documents |
| | diagram-to-bpmn | Convert diagrams to BPMN format |
| | sales-order-extractor | Extract sales order information |
| | rfqx-doc-analysis-utilities | RFQ document analysis |
| **Procurement** | intelligent-procurement-assistant | AI-powered procurement workflows |
| | intelligent-negotiation-assistant | Negotiation support with AI |
| | vendor-selection-optimization | Optimize vendor selection |
| **Analytics** | anomaly-detection | Detect anomalies in business data |
| | ai-log-analyzer | Analyze system logs with AI |
| | customer-credit-check | AI-assisted credit evaluation |
| | document-outlier-detection | Find outlier documents |
| **Business Process** | ai-powered-email-cockpit | Email classification and routing |
| | utilities-tariff-mapping-cockpit | Tariff mapping automation |
| | touchless-transactions-ai-agent | Automated GR/Invoice workflows |
| | product-catalog-search | AI-enhanced product search |
| | ai-capability-matcher | Match capabilities with AI |
---
## Quick Start
```bash
# Clone the repository
git clone [https://github.com/SAP-samples/sap-btp-ai-best-practices.git](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
| Resource | Link |
|----------|------|
| **Documentation Portal** | [https://btp-ai-bp.docs.sap/](https://btp-ai-bp.docs.sap/) |
| **GitHub Repository** | [https://github.com/SAP-samples/sap-btp-ai-best-practices](https://github.com/SAP-samples/sap-btp-ai-best-practices) |
| **Project Catalog** | [https://ai4u-website.cfapps.eu10-004.hana.ondemand.com/project-catalog](https://ai4u-website.cfapps.eu10-004.hana.ondemand.com/project-catalog) |
| **SAP AI Core Documentation** | [https://help.sap.com/docs/sap-ai-core](https://help.sap.com/docs/sap-ai-core) |
---
**License**: Apache-2.0
**Last Updated**: 2025-11-22
**Repository**: [https://github.com/secondsky/sap-skills](https://github.com/secondsky/sap-skills)

439
references/deployment-and-delivery.md Normal file
View File

@@ -0,0 +1,439 @@
# SAP BTP Deployment and Delivery - Detailed Reference
**Source**: [https://github.com/SAP-docs/btp-best-practices-guide/tree/main/docs/deploy-and-deliver](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
| Content Type | CI/CD | Cloud Transport Mgmt | CTS+ |
|--------------|-------|---------------------|------|
| Development Content (Java, HTML5, CAP) | Recommended | Recommended | - |
| SAP Cloud Integration Content | In development | Recommended | - |
| SAP HANA Cloud Artifacts | Recommended | Recommended | - |
| SAP Build Work Zone | - | Recommended | - |
| Other App-Specific Content | - | Recommended | Recommended |
| Kyma-Based Apps | Recommended | - | - |
---
## SAP Continuous Integration and Delivery
### Solution Options
| Aspect | SAP CI/CD Service | Project "Piper" |
|--------|-------------------|-----------------|
| Expertise Required | Low | Medium-to-High |
| Flexibility | Medium | High |
| Infrastructure | Ready-to-use | Requires Jenkins (or Cx Server) |
| Support | Direct SAP support | Open-source community |
| Best For | Typical SAP customers | Advanced customization |
### 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](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
```yaml
_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
```bash
# 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**:
```dockerfile
FROM node:18-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
EXPOSE 8080
CMD ["npm", "start"]
```
**Cloud Native Buildpacks**:
```bash
# 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
```bash
# 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
```yaml
# .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)
```groovy
@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
```bash
# Using Cloud Transport Management API
curl -X POST "[https://[ctms-url]/v2/files/upload"](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"](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/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/deploying-applications-866ab13.md)
- [https://github.com/SAP-docs/btp-best-practices-guide/blob/main/docs/deploy-and-deliver/delivering-applications-b39bae3.md](https://github.com/SAP-docs/btp-best-practices-guide/blob/main/docs/deploy-and-deliver/delivering-applications-b39bae3.md)

392
references/failover-and-resilience.md Normal file
View File

@@ -0,0 +1,392 @@
# SAP BTP Failover and Resilience - Detailed Reference
**Source**: [https://github.com/SAP-docs/btp-best-practices-guide/tree/main/docs/deploy-and-deliver](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**:
| Method | Effort | Best For |
|--------|--------|----------|
| Manual | High | Infrequent updates |
| CI/CD Pipeline | Medium | Regular deployments |
| Solution Export + Transport Management | Medium | Neo environments |
#### 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
```yaml
# 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
| Scenario | Components | Resources |
|----------|------------|-----------|
| **SAP Build Work Zone + Azure Traffic Manager** | Work Zone, Azure | Blog post, GitHub, Discovery Center mission |
| **SAP Build Work Zone + Amazon Route 53** | Work Zone, AWS | Blog post, GitHub |
| **CAP Applications + SAP HANA Cloud** | CAP, HANA Cloud multi-zone | GitHub repository |
| **CAP Applications + Amazon Aurora** | CAP, Aurora read replica | GitHub repository |
| **SAP Cloud Integration + Azure Traffic Manager** | CPI, Azure | GitHub, Discovery Center |
### 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
| Service | Backup Type | Retention | Notes |
|---------|-------------|-----------|-------|
| **SAP HANA Cloud** | Continuous | As configured | Database recovery supported |
| **PostgreSQL (Hyperscaler)** | Point-in-time | 14 days | Restore by creating new instance |
| **Redis** | None | N/A | No persistence support |
| **Object Store** | None | N/A | Use versioning for protection |
### 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
| Runtime | Strategy |
|---------|----------|
| **Cloud Foundry** | Multi-AZ replication within region |
| **Kyma** | Managed K8s snapshots (excludes volumes) |
| **Neo** | Cross-region data copies |
### Customer-Managed Backups
**Critical**: SAP doesn't manage backups of service configurations. You are responsible for backing up your service-specific configurations.
**Key Responsibilities**:
| Responsibility | Details |
|----------------|---------|
| **Self-Service Backup** | You must back up service configurations yourself |
| **Service Documentation Review** | Consult each service's documentation for backup capabilities |
| **Service Limitations Awareness** | Some services don't support user-specific configuration backups |
| **Risk Mitigation** | Backup frequency varies by service; prevents accidental data loss |
**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
| Strategy | Description |
|----------|-------------|
| **Namespaces** | Isolate API resources within cluster |
| **RBAC** | Manage permissions within namespaces |
| **Global Resources** | Admin-managed CRDs and global objects |
| **Policy Engines** | Gatekeeper, Kyverno for compliance |
| **Resource Quotas** | Set limits per tenant/namespace |
### Data Plane Isolation Strategies
| Strategy | Description |
|----------|-------------|
| **Network Policies** | Restrict inter-namespace traffic |
| **Centralized Observability** | Cluster-wide metrics tracking |
| **Service Mesh (Istio)** | mTLS, dedicated ingress per tenant |
### Sample Network Policy
```yaml
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
```javascript
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/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/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/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/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/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/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/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/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](https://github.com/SAP-docs/btp-best-practices-guide/blob/main/docs/set-up-and-plan/sharing-clusters-in-kyma-57ec1ea.md)

422
references/governance-and-teams.md Normal file
View File

@@ -0,0 +1,422 @@
# SAP BTP Governance and Teams - Detailed Reference
**Source**: [https://github.com/SAP-docs/btp-best-practices-guide/tree/main/docs/set-up-and-plan](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
| Area | Key Activities |
|------|----------------|
| **Organizational Structure** | Team composition definitions, IT support positions, accountability assignments |
| **Process Development** | Integration pathways, knowledge sharing, operations documentation, tool selection |
| **Resource & Change Management** | Personnel scaling, process improvements, system tools, reference materials |
| **Support Operations** | Help desk workflows, incident management protocols, change management procedures |
**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
| Document | Owner | Purpose |
|----------|-------|---------|
| **Onboarding Documentation** | Platform Engineering | Guide new projects through enrollment |
| **Security Guidelines** | Platform Engineering + Security | Define security requirements and standards |
| **Services Catalog** | Platform Engineering | Provide templated services for developers |
### Onboarding Document Contents
Every new application should document:
| Field | Description |
|-------|-------------|
| Organization/Department | Business unit owning the application |
| Application Identifier | Unique identifier for tracking |
| Business Rationale | Why this application is needed |
| Go-Live Timeline | Target production date |
| Owner | Primary responsible person |
| Access Requirements | Who needs access and what level |
| User Accessibility Scope | Internal, external, specific groups |
| System Integration Details | Connected systems and interfaces |
| Technology Stack | Languages, frameworks, services |
| Repository Location | **Keep outside SAP BTP** to prevent accidental deletion |
| Testing Approach | Testing strategy and requirements |
### Security Document Contents
**Requires security expert approval before development begins.**
| Field | Description |
|-------|-------------|
| Owner Identification | Security-responsible person |
| Business Scenario | Use case and context |
| User Classifications | Types of users and roles |
| Data Sensitivity Levels | Classification of handled data |
| Policy Compliance | Applicable policies and standards |
| Data Flow | How data moves through system |
| Data Storage | Where and how data is stored |
| Connected Systems | External integrations |
| Protocols | Communication protocols used |
| Authentication Framework | Identity and authentication approach |
| Authorization Framework | Permissions and access control |
| Audit Procedures | Logging and audit requirements |
### 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
| Aspect | Self-Service | Managed |
|--------|--------------|---------|
| Speed | Faster | Slower |
| Control | Less | More |
| Suitable For | Low-risk, sandbox | Production, sensitive |
| Governance | Light | Full |
---
## Account Administration Tools
### Available Options
| Tool | Use Case | Automation |
|------|----------|------------|
| **SAP BTP Cockpit** | GUI administration | No |
| **btp CLI** | Terminal, scripting | Yes |
| **REST APIs** | Programmatic | Yes |
| **Terraform Provider** | Infrastructure as Code | Yes |
| **SAP Automation Pilot** | Low-code automation | Yes |
### 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**:
```hcl
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
| Area | Responsibility |
|------|----------------|
| **Infrastructure** | Software updates, patches, maintenance |
| **Monitoring** | Infrastructure, OS, and service monitoring |
| **Capacity** | Capacity management and troubleshooting |
| **Incidents** | Incident management and resolution |
| **Provisioning** | Global account creation, resource provisioning |
| **HANA Operations** | Hardware, backup, recovery, security |
| **Kyma System** | `kyma-system` namespace management |
### Customer Manages
| Area | Responsibility |
|------|----------------|
| **Account Strategy** | Global account and subaccount planning |
| **Configuration** | Subaccount configuration and setup |
| **Development** | Application development and security |
| **Deployment** | Application creation, deployment, management |
| **Authorization** | Role assignments for applications |
| **Integration** | System integration and connectivity |
| **Monitoring** | Application monitoring and health checks |
| **Maintenance** | Application updates and improvements |
| **Security** | OSS vulnerability scanning, updates |
| **HANA Updates** | Trigger revision updates via self-service |
### Additional Resources
- SAP BTP Security Recommendations
- Operating Model documentation
---
## Cost Management Governance
### Commercial Model Selection
| Model | Best For |
|-------|----------|
| **Consumption-Based** | Pilots, flexibility, new workloads |
| **Subscription-Based** | Established use cases, known services |
### 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
| Level | Recommended Owner |
|-------|-------------------|
| Global Account | Platform Engineering Team/CoE |
| Directories | Designated owners with role collections |
| Subaccounts | Designated owners with role collections |
| Spaces/Namespaces | Development units |
### 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
| Subaccount | Purpose |
|------------|---------|
| **Development** | Cloud-based development, individual testing |
| **Testing** | Integration testing, production-like conditions |
| **Production** | Live applications |
### 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
| Consideration | Guidance |
|---------------|----------|
| **On-Premises Connections** | Each subaccount needs separate integration setup |
| **Geographic Selection** | Choose regions near customers for latency |
| **Regulatory Compliance** | Segregate S/4HANA tenants when legally required |
| **Team Structure** | Separate DevOps teams warrant distinct subaccounts |
---
## 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/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/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-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/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/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](https://github.com/SAP-docs/btp-best-practices-guide/blob/main/docs/shared-responsibility/shared-responsibility-model-between-you-and-sap-898509d.md)

449
references/operations-and-monitoring.md Normal file
View File

@@ -0,0 +1,449 @@
# SAP BTP Operations and Monitoring - Detailed Reference
**Source**: [https://github.com/SAP-docs/btp-best-practices-guide/tree/main/docs/go-live-and-monitor](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
| Practice | Description |
|----------|-------------|
| **HTTPS Enforcement** | Use HTTPS-only connections |
| **Location-Based Access** | Implement geographic access controls |
| **Compression** | Enable gzip compression |
| **Static Content Caching** | Cache images, CSS, JS, fonts |
| **Dynamic Content Exclusion** | Don't cache dynamic responses |
| **Cache Headers** | Respect application cache directives |
| **CSRF Protection** | Never cache CSRF tokens |
### 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
| Capability | Description |
|------------|-------------|
| **Real User Monitoring** | Track actual user experience and performance |
| **Health Monitoring** | System availability and health status |
| **Integration Monitoring** | Monitor integration flows and interfaces |
| **Exception Monitoring** | Track and alert on application errors |
| **Job Automation Monitoring** | Monitor scheduled jobs and automations |
### 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**:
```json
{
"name": "daily-cleanup",
"description": "Daily data cleanup job",
"action": "[https://my-app.cfapps.region.hana.ondemand.com/cleanup",](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](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
```json
{
"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/..."](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
```yaml
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**:
```javascript
opaTest("Should navigate to detail page", function(Given, When, Then) {
Given.iStartMyApp();
When.onTheMainPage.iPressOnTheFirstItem();
Then.onTheDetailPage.iShouldSeeTheDetailPage();
Then.iTeardownMyApp();
});
```
### Application Integration Options
| Option | Use Case |
|--------|----------|
| **Cloud Connector** | Point-to-point, on-premise connectivity |
| **SAP Cloud Integration** | Complex multi-system, mediation needs |
| **Cloud Integration Automation** | Guided workflows, reusable configs |
---
## 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
| Method | Description |
|--------|-------------|
| **Data Exports** | Export usage data for processing |
| **APIs** | Programmatic access to usage data |
| **Fixed-Rate** | Allocate based on agreed percentages |
### 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
| Strategy | Description | Use Case |
|----------|-------------|----------|
| **Blue-Green Deployment** | Two production environments, switch traffic | Zero-downtime updates |
| **Feature Flags** | Toggle features without deployment | Gradual rollouts |
| **Canary Releases** | Route percentage of traffic to new version | Risk mitigation |
### 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/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/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/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](https://github.com/SAP-docs/btp-best-practices-guide/blob/main/docs/set-up-and-plan/managing-cost-c615301.md)

420
references/security-and-authentication.md Normal file
View File

@@ -0,0 +1,420 @@
# SAP BTP Security and Authentication - Detailed Reference
**Source**: [https://github.com/SAP-docs/btp-best-practices-guide/tree/main/docs/set-up-and-plan](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
| Provider | Purpose |
|----------|---------|
| **SAP ID Service** | Preconfigured for starter scenarios and testing |
| **SAP Universal ID** | Manages official SAP community users |
### Trust Configuration Levels
| User Type | Configuration Level |
|-----------|---------------------|
| Platform Users | Global account level (applies across directories, subaccounts, environments) |
| Business Users | Individual subaccount level |
**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
| Aspect | Provisioning | Federation |
|--------|-------------|------------|
| **Mechanism** | Synchronizes users/groups between systems | Maps authorizations to user attributes in tokens |
| **Tools** | Identity Provisioning, Cloud Identity Access Governance | btp CLI, SAP BTP cockpit |
| **Advantages** | Centrally defined roles, approval workflows, automated offboarding | Simpler implementation, real-time authorization |
| **Disadvantages** | Users wait for provisioning jobs | Doesn't scale, manual role grouping, orphaned data |
| **Restrictions** | Partial for platform users (subaccount level only) | ABAP environment doesn't support |
### 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
| Environment | Requirements |
|-------------|--------------|
| ABAP | Unique email address required |
| Kyma | Unique email address required |
| Cloud Foundry | Email + IdP information |
### 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
| Team | Development | Test | Production |
|------|-------------|------|------------|
| Cloud Development Team | Full access | No access | No access |
| Platform Engineering Team | No access | Full access | Full access |
### Environment-Specific Roles
#### Cloud Foundry
| Role | Capability | Recommended For |
|------|------------|-----------------|
| Space Developer | Deploy apps, access service credentials, sensitive data | Dev team (dev only), Platform Engineering (test/prod) |
| Org Manager | Manage org settings | Platform Engineering |
| Space Manager | Manage space settings | Platform Engineering |
**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
| Method | Description | CF | Neo | Internet | On-Premise |
|--------|-------------|----|----|----------|------------|
| **NoAuthentication** | No authentication required | Yes | Yes | Yes | Yes |
| **BasicAuthentication** | Username/password (testing only) | Yes | Yes | Yes | Yes |
| **ClientCertificateAuthentication** | Mutual TLS with technical user | Yes | Yes | Yes | No |
| **PrincipalPropagation** | Forward user identity via Cloud Connector | Yes | Yes | No | Yes |
| **OAuth2SAMLBearerAssertion** | SAML to OAuth for third-party | Yes | Yes | Yes | Yes |
| **OAuth2ClientCredentials** | Client credentials grant (cached) | Yes | Yes | Yes | Yes |
| **OAuth2UserTokenExchange** | Token exchange in same tenant | Yes | No | Yes | Yes |
| **OAuth2Password** | Password grant (testing only) | Yes | No | Yes | Yes |
| **OAuth2JWTBearer** | JWT bearer for user context | Yes | No | Yes | Yes |
| **SAMLAssertion** | Generated SAML assertion | Yes | No | Yes | Yes |
| **AppToAppSSO** | Application-to-application SSO | No | Yes | Yes | No |
### 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
```yaml
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
| Level | Use Case |
|-------|----------|
| Subaccount | Organization-wide availability |
| Service Instance | Specific scenario use |
**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
| SAP Provides | You Must |
|--------------|----------|
| Security features | Implement them properly |
| Data protection-relevant functions | Configure for your requirements |
| Identity lifecycle management | Coordinate across all integrated systems |
| Documentation and guidance | Consult legal experts for your jurisdiction |
---
**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/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-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-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/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/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](https://github.com/SAP-docs/btp-best-practices-guide/blob/main/docs/set-up-and-plan/destination-authentication-methods-765423d.md)

674
references/templates-and-examples.md Normal file
View File

@@ -0,0 +1,674 @@
# SAP BTP Templates and Code Examples - Detailed Reference
**Source**: [https://github.com/SAP-docs/btp-best-practices-guide](https://github.com/SAP-docs/btp-best-practices-guide)
This reference contains complete templates, manifests, and configuration examples from the official documentation.
---
## Getting Started Checklist - Complete Steps
### Phase 1: Fulfill Prerequisites (9 Steps)
| Step | Action | Resources |
|------|--------|-----------|
| 1 | **Platform Familiarization** | SAP BTP Guidance Framework, Learning Journey: Discover SAP BTP, Basic Platform Concepts, Shared Responsibility Model |
| 2 | **Discovery Center Exploration** | Explore services, missions, reference architectures at [https://discovery-center.cloud.sap/](https://discovery-center.cloud.sap/) |
| 3 | **Project Identification** | Identify pilot projects using SAP BTP Use Cases page |
| 4 | **Free Tier Consideration** | Note: "Only community support is available for free tier service plans and they are not subject to SLAs" |
| 5 | **Commercial Model Selection** | Choose subscription or consumption-based; review SAP BTP and Integration Suite pricing |
| 6 | **SLA Review** | Review SAP BTP Service Description Guide and SAP Trust Center |
| 7 | **Onboarding Confirmation** | Receive onboarding email with cockpit access; existing users contact global account admin |
| 8 | **Customer Number Acquisition** | Obtain customer number for support purposes |
| 9 | **Team Building** | Establish Platform Engineering Team (CoE) and Cloud Development Team |
### Phase 2: Get Started (4 Steps)
1. **Onboard to SAP Cloud Identity Services** - Configure identity provider
2. **Set Up Account Model** - Choose runtime (Kyma vs Cloud Foundry)
3. **Configure Security Model** - Establish security and compliance framework
4. **Create Enrollment Process** - Define onboarding workflow for development projects
### Phase 3: Implement (4 Steps)
1. **Develop and Deploy** - Use SAP Cloud Application Programming Model
2. **Test and Evaluate** - Thorough testing before production
3. **Go Live** - Launch to production
4. **Improve or Retire** - Continuous enhancement or decommission
---
## Account Administration Responsibilities
| Level | Key Responsibilities |
|-------|---------------------|
| **Global Account** | Appoint administrators; manage entitlements and quotas for distribution |
| **Directory** | Manage member access; oversee entitlements (if enabled) |
| **Subaccount** | Assign business roles; manage member access |
**Recommendation**: Appoint substitute administrators at each level to ensure continuity.
---
## Deployment Methods by Runtime - Complete Reference
### Cloud Foundry and Neo Environments
| Application Type | Deployment Tools |
|------------------|------------------|
| **Java Applications** | SAP BTP cockpit, Cloud Foundry CLI, Console client (Neo) |
| **HTML5 Applications** | SAP Business Application Studio, Cloud Foundry CLI, SAP BTP cockpit |
| **Node.js Applications** | SAP Business Application Studio, Cloud Foundry CLI |
| **SAP HANA XSA Applications** | SAP HANA Deployment Infrastructure (HDI) from Business Application Studio, Cloud Foundry CLI |
| **Custom Buildpacks** | Deployment dependent on buildpack specifications |
**Key Recommendation**: Archive all components into a Multitarget Application (MTA) with deployment descriptor.
### Kyma Environment
| Approach | Description |
|----------|-------------|
| **Standard Dockerfile** | Package application in Linux Docker image |
| **Cloud Native Buildpacks** | Alternative to Dockerfile for containerization |
| **Kubernetes Jobs** | Use HTML5 application deployer |
| **Automation (Production)** | SAP Continuous Integration and Delivery with Helm charts |
**Supported Technologies**: Java, Node.js, Python, Scala, .Net, and others when packaged as Linux Docker images.
**Production Recommendation**: Use automation tools rather than manual deployment processes.
---
## Directory Template
When creating new directories, document the following:
| Field | Requirement | Example |
|-------|-------------|---------|
| **Name** | Follow naming guidelines | `hr-applications` |
| **Owners** | Minimum two owners recommended | Platform Engineering Team leads |
| **Description** | Developer audience, department, application types, runtimes, subscriptions | "HR department applications using Cloud Foundry, CAP framework" |
| **Cost Center** | Define accounting requirements | `CC-HR-001` |
| **Enrollment** | Describe project enrollment process | "Submit via ServiceNow, approval within 5 days" |
---
## Kyma RBAC Complete Manifest Examples
### ClusterRole: cluster-viewer
Provides view permissions across all resources:
```yaml
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: cluster-viewer
rules:
- apiGroups: ['*']
verbs: ['get', 'list', 'watch']
resources: ['*']
```
### ClusterRole: common-resource-viewer
Enables viewing Kyma-specific objects (applications, gateways):
```yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: common-resource-viewer
rules:
- verbs: [get, list, watch]
apiGroups:
- applicationconnector.kyma-project.io
- networking.istio.io
resources:
- applications
- gateways
```
### Operator View Access
```yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: cluster-admin-view-crb
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-viewer
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: Group
name: <operators-group-name>
```
### Operator Impersonation Setup (3 Manifests)
**Step 1 - Bind virtual user to cluster-admin role:**
```yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: cluster-admin-crb
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: User
name: cluster-admin
```
**Step 2 - Create impersonation ClusterRole:**
```yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: cluster-admin-impersonator
rules:
- apiGroups: ['']
resources: ['users']
verbs: ['impersonate']
resourceNames: ['cluster-admin']
```
**Step 3 - Bind impersonation to operators group:**
```yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: cluster-admin-impersonate-crb
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-admin-impersonator
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: Group
name: <operators-group-name>
```
### Developer Namespace Admin (Dev/Test)
```yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: dev-team-admin-rb
namespace: <namespace>
subjects:
- kind: Group
name: <dev-team-group-name>
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: admin
apiGroup: rbac.authorization.k8s.io
```
### Developer Production Impersonation (4 Manifests)
**Step 1 - Create app-specific impersonation ClusterRole:**
```yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: app-admin-impersonator
rules:
- apiGroups: ['']
resources: ['users']
verbs: ['impersonate']
resourceNames: ['app-admin-vuser']
```
**Step 2 - Bind impersonation to team:**
```yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: app-team-impersonation-crb
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: app-admin-impersonator
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: Group
name: <app-team-group-name>
```
**Step 3 - Bind virtual user to admin in namespace:**
```yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: app-admin-rb
namespace: <namespace>
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: admin
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: User
name: app-admin-vuser
```
**Step 4 - Provide read access to namespace:**
```yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: namespace-viewer-rb
namespace: <namespace>
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-viewer
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: Group
name: <app-team-group-name>
```
### Common Resource Viewer Binding
```yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: developers-common-resources-crb
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: common-resource-viewer
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: Group
name: <developers-group-name>
```
---
## Multi-Region Reference Use Cases - Complete Links
**Note**: Repository structures may change. Always verify current paths at the repository root.
### Use Case 1: SAP Build Work Zone + Azure Traffic Manager
| Resource Type | Link |
|---------------|------|
| **Blog Post** | "Multi-region High Availability architecture for SAP BTP Launchpad Service using Azure Traffic Manager" (SAP Community) |
| **GitHub** | [https://github.com/SAP-samples/btp-services-intelligent-routing](https://github.com/SAP-samples/btp-services-intelligent-routing) |
| **Discovery Center** | Mission: "Route Multi-Region Traffic to SAP BTP Services Intelligently" |
### Use Case 2: SAP Build Work Zone + Amazon Route 53
| Resource Type | Link |
|---------------|------|
| **Blog Post** | "High Availability of SAP Build Work Zone with Amazon Route 53" (SAP Community) |
| **GitHub** | [https://github.com/SAP-samples/btp-services-intelligent-routing](https://github.com/SAP-samples/btp-services-intelligent-routing) |
### Use Case 3: CAP Applications + SAP HANA Cloud Multi-Zone
| Resource Type | Link |
|---------------|------|
| **GitHub** | [https://github.com/SAP-samples/cap-distributed-resiliency](https://github.com/SAP-samples/cap-distributed-resiliency) |
### Use Case 4: CAP Applications + Amazon Aurora Read Replica
| Resource Type | Link |
|---------------|------|
| **GitHub** | [https://github.com/SAP-samples/cap-distributed-resiliency](https://github.com/SAP-samples/cap-distributed-resiliency) |
### Use Case 5: SAP Cloud Integration + Azure Traffic Manager
| Resource Type | Link |
|---------------|------|
| **GitHub** | [https://github.com/SAP-samples/btp-services-intelligent-routing](https://github.com/SAP-samples/btp-services-intelligent-routing) |
| **Discovery Center** | Mission: "Route Multi-Region Traffic to SAP BTP Services Intelligently" |
**Discovery Center URL**: [https://discovery-center.cloud.sap/](https://discovery-center.cloud.sap/)
---
## Neo Environment Monitoring Table
| Application Type | Monitoring Options | Resources |
|------------------|-------------------|-----------|
| **Java Applications** | Application monitoring, custom thresholds, availability checks, heap/thread dumps, email alerts, logging APIs | Monitoring Java Applications; Using Logs in Cockpit for Java Applications |
| **SAP HANA XS Applications** | Application monitoring, availability checks, HTTP checks, email alerts, database health statistics | Monitoring Database Systems |
| **HTML5 Applications** | Application monitoring, custom checks, email alerts, application logging | Monitoring HTML5 Applications; Using Logs in Cockpit |
**Additional**: Dynatrace SaaS monitoring integration available for Java applications.
---
## Cluster Sharing Isolation Strategies
### Control Plane Isolation
| Strategy | Description | Implementation |
|----------|-------------|----------------|
| **Namespaces** | Logical grouping isolating API resources | Each team/project gets dedicated namespace |
| **RBAC** | Control user access and permissions | Scope activities to respective namespaces |
| **Global Resources** | Admin-managed cluster-wide resources | Centrally manage CRDs affecting all tenants |
| **Policy Engines** | Enforce tenant policies | Gatekeeper or Kyverno for compliance |
| **Resource Controls** | Fair consumption management | Resource quotas, limit ranges, Pod priorities |
### Data Plane Isolation
| Strategy | Description | Implementation |
|----------|-------------|----------------|
| **Network Policies** | Control traffic flow | Restrict inter-namespace communication |
| **Centralized Observability** | Cluster-wide metrics | Tenant-restricted data access |
| **Istio Service Mesh** | Advanced traffic control | mTLS between Pods, dedicated ingress per tenant |
### Sample Network Policy (Deny Cross-Namespace)
```yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: deny-cross-namespace
namespace: tenant-a
spec:
podSelector: {}
policyTypes:
- Ingress
- Egress
ingress:
- from:
- namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: tenant-a
egress:
- to:
- namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: tenant-a
- to:
- namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: kube-system
ports:
- protocol: UDP
port: 53
```
---
## CI/CD Configuration Templates
### SAP Continuous Integration and Delivery Pipeline Config
```yaml
# .pipeline/config.yml
general:
buildTool: 'mta'
productiveBranch: 'main'
service:
buildToolVersion: 'MBTJ11N14'
stages:
Build:
mtaBuild: true
Additional Unit Tests:
npmExecuteScripts:
runScripts:
- 'test'
Acceptance:
cloudFoundryDeploy:
deployTool: 'mtaDeployPlugin'
deployType: 'standard'
cfOrg: 'my-org'
cfSpace: 'dev'
cfCredentialsId: 'cf-credentials'
Release:
cloudFoundryDeploy:
deployTool: 'mtaDeployPlugin'
deployType: 'standard'
cfOrg: 'my-org'
cfSpace: 'prod'
cfCredentialsId: 'cf-credentials'
```
### Project "Piper" Jenkinsfile Example
```groovy
@Library('piper-lib-os') _
node {
stage('Prepare') {
checkout scm
setupCommonPipelineEnvironment script: this
}
stage('Build') {
mtaBuild script: this
}
stage('Unit Tests') {
npmExecuteScripts script: this, runScripts: ['test']
}
stage('Deploy to Dev') {
cloudFoundryDeploy script: this,
deployTool: 'mtaDeployPlugin',
cfOrg: 'my-org',
cfSpace: 'dev'
}
stage('Integration Tests') {
// Add integration test execution
}
stage('Deploy to Prod') {
cloudFoundryDeploy script: this,
deployTool: 'mtaDeployPlugin',
cfOrg: 'my-org',
cfSpace: 'prod'
}
}
```
---
## MTA Deployment Descriptor Template
```yaml
_schema-version: "3.1"
ID: my-application
version: 1.0.0
description: "SAP BTP Application"
parameters:
enable-parallel-deployments: true
build-parameters:
before-all:
- builder: custom
commands:
- npm ci
- npm run build
modules:
- name: my-app-srv
type: nodejs
path: gen/srv
parameters:
buildpack: nodejs_buildpack
memory: 256M
provides:
- name: srv-api
properties:
srv-url: ${default-url}
requires:
- name: my-app-db
- name: my-app-auth
- name: my-app-db-deployer
type: hdb
path: gen/db
parameters:
buildpack: nodejs_buildpack
requires:
- name: my-app-db
- name: my-app-ui
type: approuter.nodejs
path: app/
parameters:
keep-existing-routes: true
disk-quota: 256M
memory: 256M
requires:
- name: srv-api
group: destinations
properties:
name: srv-api
url: ~{srv-url}
forwardAuthToken: true
- name: my-app-auth
resources:
- name: my-app-db
type: com.sap.xs.hdi-container
parameters:
service: hana
service-plan: hdi-shared
- name: my-app-auth
type: org.cloudfoundry.managed-service
parameters:
service: xsuaa
service-plan: application
path: ./xs-security.json
```
---
## Kyma Helm Chart Template
### Chart.yaml
```yaml
apiVersion: v2
name: my-kyma-app
description: A Helm chart for SAP BTP Kyma deployment
type: application
version: 1.0.0
appVersion: "1.0.0"
```
### values.yaml
```yaml
replicaCount: 2
image:
repository: my-registry/my-app
pullPolicy: IfNotPresent
tag: "latest"
service:
type: ClusterIP
port: 8080
ingress:
enabled: true
className: ""
annotations:
kubernetes.io/ingress.class: istio
hosts:
- host: my-app.kyma.example.com
paths:
- path: /
pathType: Prefix
resources:
limits:
cpu: 500m
memory: 256Mi
requests:
cpu: 100m
memory: 128Mi
autoscaling:
enabled: true
minReplicas: 2
maxReplicas: 10
targetCPUUtilizationPercentage: 80
nodeSelector: {}
tolerations: []
affinity: {}
```
### templates/deployment.yaml
```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: {{ include "my-kyma-app.fullname" . }}
labels:
{{- include "my-kyma-app.labels" . | nindent 4 }}
spec:
{{- if not .Values.autoscaling.enabled }}
replicas: {{ .Values.replicaCount }}
{{- end }}
selector:
matchLabels:
{{- include "my-kyma-app.selectorLabels" . | nindent 6 }}
template:
metadata:
labels:
{{- include "my-kyma-app.selectorLabels" . | nindent 8 }}
spec:
containers:
- name: {{ .Chart.Name }}
image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
imagePullPolicy: {{ .Values.image.pullPolicy }}
ports:
- name: http
containerPort: 8080
protocol: TCP
livenessProbe:
httpGet:
path: /health
port: http
initialDelaySeconds: 30
periodSeconds: 10
readinessProbe:
httpGet:
path: /health
port: http
initialDelaySeconds: 5
periodSeconds: 5
resources:
{{- toYaml .Values.resources | nindent 12 }}
```
---
**Source Documentation**:
- [https://github.com/SAP-docs/btp-best-practices-guide](https://github.com/SAP-docs/btp-best-practices-guide)
- [https://github.com/SAP-samples/btp-services-intelligent-routing](https://github.com/SAP-samples/btp-services-intelligent-routing)
- [https://github.com/SAP-samples/cap-distributed-resiliency](https://github.com/SAP-samples/cap-distributed-resiliency)