Initial commit
This commit is contained in:
Zhongwei Li
12
.claude-plugin/plugin.json
Normal file
12
.claude-plugin/plugin.json
Normal 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
3
README.md
Normal 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
447
SKILL.md
Normal 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
77
plugin.lock.json
Normal 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
366
references/account-models.md
Normal 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
234
references/ai-development-best-practices.md
Normal 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
439
references/deployment-and-delivery.md
Normal 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
392
references/failover-and-resilience.md
Normal 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
422
references/governance-and-teams.md
Normal 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
449
references/operations-and-monitoring.md
Normal 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
420
references/security-and-authentication.md
Normal 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
674
references/templates-and-examples.md
Normal 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)
|
||||||
Reference in New Issue
Block a user