commit bd301d195d5385b585e6ce01e075ee82c5a9d894 Author: Zhongwei Li Date: Sun Nov 30 08:54:47 2025 +0800 Initial commit diff --git a/.claude-plugin/plugin.json b/.claude-plugin/plugin.json new file mode 100644 index 0000000..dcd37d5 --- /dev/null +++ b/.claude-plugin/plugin.json @@ -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": [ + "./" + ] +} \ No newline at end of file diff --git a/README.md b/README.md new file mode 100644 index 0000000..5e38fff --- /dev/null +++ b/README.md @@ -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. diff --git a/SKILL.md b/SKILL.md new file mode 100644 index 0000000..fa5a87f --- /dev/null +++ b/SKILL.md @@ -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) diff --git a/plugin.lock.json b/plugin.lock.json new file mode 100644 index 0000000..bf6ed4b --- /dev/null +++ b/plugin.lock.json @@ -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": [] + } +} \ No newline at end of file diff --git a/references/account-models.md b/references/account-models.md new file mode 100644 index 0000000..e7d130c --- /dev/null +++ b/references/account-models.md @@ -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) diff --git a/references/ai-development-best-practices.md b/references/ai-development-best-practices.md new file mode 100644 index 0000000..3643ce3 --- /dev/null +++ b/references/ai-development-best-practices.md @@ -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) diff --git a/references/deployment-and-delivery.md b/references/deployment-and-delivery.md new file mode 100644 index 0000000..16f4afa --- /dev/null +++ b/references/deployment-and-delivery.md @@ -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) diff --git a/references/failover-and-resilience.md b/references/failover-and-resilience.md new file mode 100644 index 0000000..a1bd894 --- /dev/null +++ b/references/failover-and-resilience.md @@ -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) diff --git a/references/governance-and-teams.md b/references/governance-and-teams.md new file mode 100644 index 0000000..06299fd --- /dev/null +++ b/references/governance-and-teams.md @@ -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) diff --git a/references/operations-and-monitoring.md b/references/operations-and-monitoring.md new file mode 100644 index 0000000..f60a34e --- /dev/null +++ b/references/operations-and-monitoring.md @@ -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) diff --git a/references/security-and-authentication.md b/references/security-and-authentication.md new file mode 100644 index 0000000..c263acc --- /dev/null +++ b/references/security-and-authentication.md @@ -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) diff --git a/references/templates-and-examples.md b/references/templates-and-examples.md new file mode 100644 index 0000000..53e1f8a --- /dev/null +++ b/references/templates-and-examples.md @@ -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: +``` + +### 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: +``` + +### Developer Namespace Admin (Dev/Test) + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +kind: RoleBinding +metadata: + name: dev-team-admin-rb + namespace: +subjects: + - kind: 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: +``` + +**Step 3 - Bind virtual user to admin in namespace:** + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +kind: RoleBinding +metadata: + name: app-admin-rb + 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: +roleRef: + apiGroup: rbac.authorization.k8s.io + kind: ClusterRole + name: cluster-viewer +subjects: + - apiGroup: rbac.authorization.k8s.io + kind: 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: +``` + +--- + +## 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)